SvelteKit 3 вышел в превью: shallow routing внутри goto, новые модули и список ломающих изменений

Команда Svelte выложила первое публичное превью SvelteKit 3 — следующей мажорной версии популярного фреймворка (web framework — каркас для создания сайтов и веб‑приложений) поверх Svelte. Серия предварительных сборок 3.0.0-next вышла в конце июля, а 1 августа проектная команда собрала все изменения в ежемесячном обзоре «What's new in Svelte». До стабильного релиза ещё далеко, но именно сейчас видно, что именно сломается при переходе и ради чего.

Ниже — разбор ключевых нововведений: что поменялось в маршрутизации, какие появились модули, какие API объявлены устаревшими и как всё это касается тех, кто уже держит проекты на SvelteKit 2.

Что вышло и в каком это статусе

Речь идёт о серии предварительных (preview — раннее тестовое) сборок: от 3.0.0-next.5 до 3.0.0-next.13. Это «next»‑канал, то есть версии для экспериментов и обратной связи, а не для боевых проектов. Параллельно продолжает жить и обновляться стабильная ветка SvelteKit 2 — на момент обзора это релизы линейки 2.69.0–2.70.0, а само ядро Svelte дошло до 5.56.8 с исправлениями гидратации (hydration — «оживление» серверной разметки на клиенте).

Практический вывод простой: попробовать SvelteKit 3 в отдельной ветке уже можно и полезно, но переносить туда прод пока рано — API ещё меняется от сборки к сборке.

Главное: shallow routing переехал внутрь goto

Самое заметное изменение касается shallow routing (мелкая маршрутизация — изменение URL и записи в истории браузера без полноценной навигации и перезагрузки данных). Это то, на чём обычно строят модальные окна, боковые панели и просмотрщики: адрес в строке меняется, а страница остаётся на месте.

Раньше для этого использовали отдельные функции pushState и replaceState из модуля $app/navigation. В SvelteKit 3 эту логику встроили прямо в универсальную функцию перехода goto: появилась опция state для передачи состояния и параметр persistState, который управляет тем, сохраняется ли состояние между переходами. Идея — не держать два похожих механизма навигации, а свести их к одному предсказуемому API.

Для разработчика это означает конкретную работу при миграции: места, где вызывались pushState/replaceState, придётся переписать на новый goto с опцией state. Взамен — меньше «магии» и единая точка входа для любых переходов.

Меньше опций — меньше путаницы

Заодно в goto навели порядок с настройками. Две отдельные опции — noScroll (не прокручивать наверх) и keepFocus (сохранить фокус) — свернули в один параметр reset. Теперь поведением прокрутки и фокуса управляют через него, а не через набор разрозненных флагов.

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

Новые модули: $app/manifest и $app/service-worker

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

$app/manifest

Новый модуль $app/manifest открывает интроспекцию сборки (build introspection — возможность программно узнать, из чего собран проект): список маршрутов, ассетов и прочих артефактов сборки. Это удобно для инструментов, генераторов карт сайта, кастомной аналитики маршрутов и любых сценариев, где приложению нужно «знать» собственную структуру.

$app/service-worker

Модуль для сервис‑воркеров (service worker — фоновый скрипт, отвечающий за кэширование и офлайн‑режим) переехал: вместо прежнего $service-worker теперь используется $app/service-worker. Смена не косметическая — она приводит именование к единому пространству $app/*, но старый импорт перестанет работать, и его нужно поправить.

Ломающие изменения, к которым стоит готовиться

Мажорная версия на то и мажорная — вместе с удобствами приезжает пачка breaking changes (ломающих изменений). Вот те, что уже видны в превью‑сборках:

• Обработка ошибок. Функция error(status, message, {...}) теперь требует сообщение — вызвать её без текста ошибки больше нельзя.
• Алиас для библиотеки. Привычный $lib заменяется на #lib — это меняет то, как импортируется код из папки библиотеки проекта.
• Переменные окружения. Хелпер defineEnvVars переехал в отдельный подпуть @sveltejs/kit/env; появились валидаторы переменных окружения.
• Переименование типов. Тип Pathname стал Path, а Asset — AssetPath. Проектам на TypeScript это заденет типизацию.
• Маршрутизация. Изменились приоритеты конфигурации маршрутов и правила специальных имён файлов; обработку CORS (cross‑origin — межсайтовые запросы) делегировали Vite.

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

Формы и валидация стали удобнее

Отдельно подтянули работу с формами. Для удалённых форм (remote forms — формы, чьи данные обрабатываются на сервере через встроенный механизм SvelteKit) добавили свойство submitted, а также помощники валидации: dirty() (было ли поле изменено) и field.touched() (касался ли пользователь поля). Это те самые мелочи, из которых складывается адекватный UX (user experience — опыт взаимодействия) форм: показать ошибку не сразу, а после того как человек ушёл из поля, или подсветить только реально изменённые данные.

Что ещё приехало по мелочи

В превью также появились продакшен‑сорсмапы (production sourcemaps — карты исходников для отладки собранного кода в бою) и автоматическое определение платформы развёртывания по типам ответов и событий — меньше ручной конфигурации под конкретный хостинг. Улучшили и инструментарий: типизацию страницы ошибок +error.svelte без настройки, определение пакетного менеджера в CLI sv, а также инспектор компонентов с контекстным меню по стеку.

Почему это важно

SvelteKit 3 — это не революция ради революции, а наведение порядка: один механизм навигации вместо двух, единое пространство модулей $app/*, более строгие и предсказуемые API. Такой «прибирающий» мажор типичен для зрелых фреймворков — так же, как переход TypeScript на новый компилятор или обновления рантайма в свежих релизах Node.js, экосистема веб‑разработки продолжает избавляться от исторического балласта.

Что делать уже сейчас: если вы ведёте проект на SvelteKit 2, заведите тестовую ветку и прогоните сборку на 3.0.0-next, чтобы заранее увидеть, где именно всплывут pushState/replaceState, $lib, invalidateAll и вызовы error() без сообщения. Это дешевле сделать заранее, порциями, чем в день выхода стабильной версии. Обновлять прод пока не нужно — но иметь готовый список правок к моменту релиза точно стоит.