На моём ПК игра работала, а на смартфонах ломалась: ловушка деплоя, которую я не заметил

Я опубликовал веб-игру.

На моём компьютере всё работало. Исправленный код уже был на GitHub. Деплой завершился успешно.

Но на некоторых смартфонах игра всё равно ломалась.

В Analytics оставалась ошибка:

SyntaxError: Unexpected token '<'

Я работал с JavaScript. Откуда вдруг взялся символ «<»?

Это произошло во время разработки моей веб-игры ORA Quest. Самым полезным оказался не «волшебный фикс», а понимание того, что на самом деле часто означает эта ошибка.

Виноват может быть вовсе не символ «<»

Сначала я искал синтаксическую ошибку в JavaScript: случайный символ, сломанный JSON, пропущенную запятую.

Но при Unexpected token '<' стоит первым делом проверить другое: не запросил ли браузер JavaScript или JSON, а сервер вместо этого вернул HTML.

Например, браузер запрашивает game.js и ожидает JavaScript. Но сервер возвращает страницу ошибки, начинающуюся с <!DOCTYPE html>.

Браузер пытается разобрать HTML как JavaScript, доходит до первого < и падает.

То есть проблема может быть не в символе. Браузер просто получил не тот тип содержимого.

Хуже всего, когда ошибка есть не у всех

Именно это делало проблему особенно неприятной.

На ПК игра работала. На одном смартфоне тоже. На другом — нет. В браузере внутри соцсети — тоже нет.

Очень легко попасть в цикл: исправил код → задеплоил → открыл на своём ПК → работает → решил, что всё готово.

Я раньше проверял именно так.

Но если причина связана с кэшем, браузером, старым файлом или конкретным маршрутом запроса, собственный компьютер разработчика может создать ложное ощущение, что проблема исчезла.

Пять вещей, которые я проверяю теперь в первую очередь

  1. Открыть напрямую URL проблемного JS- или JSON-файла.
  2. Убедиться, что ответ действительно JavaScript или JSON.
  3. Проверить, не возвращается ли вместо него 404, страница входа, WordPress или другой HTML.
  4. Сверить файл на продакшн-сервере с тем, что ожидается из GitHub.
  5. Проверить на другом устройстве или браузере, не полагаясь на тот же кэш.

Первый пункт особенно полезен.

Вместо того чтобы снова менять код потому, что «ошибка выглядит как JavaScript», лучше сначала спросить:

что на самом деле возвращает этот URL?

Этот вопрос может сэкономить много бесполезных правок.

Правильный код на GitHub ещё не означает правильный продакшн

Это я тоже понял на практике.

Код в репозитории может быть правильным, а пользователь всё равно получает что-то другое.

Между GitHub и игроком могут находиться автоматизация деплоя, хостинг, WordPress, серверный или CDN-кэш, кэш браузера и встроенный браузер приложения.

Достаточно одному слою отдать старый файл или неожиданный ответ — и появляется фраза: «Но я же это уже исправил».

Поэтому моё определение «исправлено» изменилось.

Исправление не закончено, когда правильный commit уже в репозитории. Оно закончено, когда реальный продакшн-URL работает в условиях, похожих на условия пользователя.

Важно не только убрать ошибку, но и сделать следующую понятнее

Раньше моей целью было просто заставить ошибку исчезнуть.

Теперь я стараюсь ещё и оставить достаточно информации, чтобы понять её, если она вернётся.

Какой файл упал? Какой URL запрашивался? Какое окружение? Какая сборка работала?

Тогда следующий вопрос звучит уже не «опять этот странный баг», а «это та же причина, что и в прошлый раз, или новая?».

В одиночной разработке много времени уходит не на код, а на понимание реальности

До того как я начал делать веб-игры, мне казалось, что разработка — это персонажи, сюжет и программирование.

На практике огромное количество времени уходит на вопросы вроде: почему ломается только это устройство? почему всё ещё загружается вчерашний JavaScript? почему URL JSON возвращает HTML?

Каждый раз, когда я понимаю одну такую проблему, круг вещей, которые я могу сделать дальше, становится немного шире.

Главный урок из Unexpected token '<' для меня простой:

код, который вы написали, и файл, который реально получает пользователь, — не всегда одно и то же.

Если вы столкнулись с этой ошибкой, прежде чем переписывать JavaScript, откройте проблемный JS- или JSON-URL напрямую. Если увидите HTML, это уже очень важная подсказка.

Я учусь на таких ошибках, пока создаю ORA Quest. Если интересно, во что превращаются все эти часы отладки, можно бесплатно попробовать демо ORA Quest.

コメント