SvelteKit 3: перенос конфигурации ещё не завершает миграцию

Переход на SvelteKit 3 не заканчивается переносом настроек из svelte.config.js в Vite plugin. Нужно согласовать зависимости, разобрать оставшиеся ручные задачи и проверить действия пользователя. Успешная работа мигратора означает выполненные преобразования кода, а не принятую совместимость всего приложения.

Что выпущено и какую помощь обещает мигратор

Стабильный SvelteKit 3 представлен 1 октября 2026 года. Команда предлагает автоматизированный перенос части кода и список TODO для оставшейся работы. В анонсе отдельно отмечено, что remote functions ещё не готовы окончательно и связаны с экспериментальным Async Svelte. Не следует приписывать всей новой ветке одинаковый статус каждой возможности.

Руководство миграции советует сначала обновиться до последней 2.x, чтобы увидеть адресные предупреждения. Минимумы новой ветки на дату проверки: Node 22.17, TypeScript 6, Svelte 5.57.1, Vite 8.0.12 и vite-plugin-svelte 7. Это не означает, что произвольная комбинация остальных пакетов проекта совместима.

Разделите перенос на три результата

Первый результат — изменение файлов и зависимостей. Второй — устранение конкретных предупреждений и нерешённых задач. Третий — подтверждение поведения приложения на целевом размещении. Если в отчёте есть только список заменённых файлов, последний результат пока отсутствует.

Для каждого TODO назначьте ответственного и ожидаемое наблюдение. Формулировка «проверить форму» слишком широка. Лучше указать, какая форма, куда отправляется, где должен появиться пользователь после успеха и что происходит при ошибке данных. Такой пункт можно принять или вернуть на доработку без спора о смысле слова «проверено».

Конфигурация перестаёт быть отдельным старым файлом

Согласно руководству, настройки передаются Vite plugin, а svelte.config.js больше не поддерживается. Алиас $lib заменяется на объявляемый через imports алиас #lib. Перенос поэтому затрагивает не только имя файла: нужно проверить, откуда инструменты реально получают настройки и как разрешаются импорты.

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

Матрица проверки: от файла конфигурации до действия пользователя

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

Отправка формы может изменить страницу результата

Руководство отдельно описывает формы с use:enhance и action на другой странице: после отправки они переходят на неё вместо сохранения текущей страницы. Если приложение рассчитывало на прежний экран, нужно пересмотреть именно пользовательский путь, а не ограничиваться отсутствием ошибки в консоли.

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

Сборочная среда и размещение должны быть согласованы

Локально доступная версия Node не описывает окружение сборочного агента и рабочей платформы. Сохраните выбранный состав зависимостей и способ получения артефакта. Вопрос к подрядчику должен звучать конкретно: какая поставка проверена на каком размещении и что осталось за пределами проверки.

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

Когда переход можно принимать

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

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

Для разработки веб-приложения такая матрица помогает сформировать приёмку. В доработке проекта отдельно оценивайте изменения поведения, а при переносе на другое размещение проверяйте среду и данные. Тарифы и объём работ определяются составом конкретного проекта, а не номером версии фреймворка.