Vite после релиза не загружает модуль: как проверить старый чанк

Если Vite после релиза сообщает Failed to fetch dynamically imported module, сопоставьте запрошенный адрес модуля с версией открытого клиента и файлами релиза. Старый клиент может ссылаться на удалённый чанк. Но то же сообщение бывает при сетевой ошибке или блокировке запроса: сначала подтвердите причину, затем выбирайте способ обновления.

Почему новый посетитель работает, а старая вкладка ломается

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

В руководстве Vite по сборке описан случай, когда хостинг удаляет ресурсы предыдущего развёртывания, а старый клиент ещё ссылается на них. Это объяснение возможного расхождения версий. Сам текст ошибки не подтверждает, что именно оно случилось на вашем сайте.

Первое доказательство — адрес и результат запроса

Сохраните точный URL модуля, наблюдаемый ответ, версию клиента и действие перед ошибкой. Важен именно тот запрос, который не выполнился, а не случайный файл JavaScript с похожим именем. Если есть промежуточная доставка ресурсов, проверьте и её состояние.

В разделе Vite Troubleshooting среди причин указаны плохое сетевое соединение, расширения браузера и рассогласование версий. Они требуют разного исправления. Не назначайте очистку всего кеша единственным действием для каждой из этих ситуаций.

Четыре учебных наблюдения, четыре разных вывода

Пусть релиз А использовал условный файл report-a7.js, а релиз Б — report-b9.js. Названия придуманы для объяснения. В старой вкладке переход к отчёту по-прежнему требует первый файл. Таблица показывает, какие выводы допустимы при разных подтверждённых наблюдениях.

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

Что сообщает vite:preloadError

Событие vite:preloadError сигнализирует об ошибке загрузки динамического импорта, а event.payload содержит исходную ошибку. В документации также описано подавление её выбрасывания через event.preventDefault(). Это механизм обработки сигнала, не восстановление отсутствующего файла.

Если обработчик только скрывает ошибку, пользователь может остаться перед неработающей кнопкой без объяснения. Нужно определить видимое состояние раздела: что не загрузилось, сохранена ли введённая работа и какое действие доступно дальше. Сама установка обработчика не завершает исправление.

Как предложить обновление без потери формы

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

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

Перезагрузка не гарантирует решение сетевой блокировки или неверного маршрута ресурсов. Поэтому её полезность связывают с установленной причиной и проверяемой версией. Счётчик повторов сам по себе не превращает неверный диагноз в правильный.

Что изменить в порядке развёртывания

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

Для старых ресурсов согласуйте срок и способ сохранения с реальными маршрутами и условиями проекта. В статье нет универсального количества дней: длительность открытых сессий и модель релизов различаются. Важен проверяемый договор о совместимости, а не произвольная цифра.

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

Приёмка на двух версиях клиента

1. Подготовьте контролируемые версии А и Б в тестовой среде и опишите динамически открываемый раздел.
2. Откройте клиент А, сохранив учебный черновик, но ещё не загрузив нужный раздел.
3. Разверните Б по проверяемому порядку и зафиксируйте доступность ресурсов обеих версий.
4. В старом клиенте откройте раздел и проверьте успешную загрузку либо предусмотренный переход.
5. Отдельно проверьте сетевую ошибку, повторный отказ и судьбу черновика.
6. В свежем клиенте проверьте тот же маршрут и сохраните фактический протокол результата.

Это план проверки, а не сообщение о выполненной здесь сборке или испытании сайта. Одного посещения после релиза мало: такой тест обычно проверяет свежий клиент, а проблема относится к уже открытому. Для приёмки нужен именно переход через смену версии.

Что передать в поддержку

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

При разработке веб-приложения совместимость открытого клиента с релизом стоит включить в критерии публикации. Проверяемый результат — пользователь продолжает работу или управляемо обновляется, а отсутствующий модуль не превращает незавершённую форму в бесконечный цикл перезагрузок.