SvelteKit 3.0: переход на Vite-конфигурацию и чистые subpath-импорты

Разработка на современных веб-фреймворках долгое время сопровождалась раздражающей дилеммой двух конфигурационных файлов. Инженеру приходилось постоянно гадать: настраивать адаптер развертывания в svelte.config.js или бандлер в vite.config.ts? Вдобавок фирменные алиасы путей вроде $lib часто сбивали с толку сторонние линтеры, среды тестирования и языковые серверы TypeScript, требуя написания костылей для распознавания путей.

Команда Svelte анонсировала мажорный релиз SvelteKit 3.0. Главный вектор обновления — фундаментальное очищение проекта от устаревших соглашений, бесшовная стандартизация с экосистемой Node.js и объединение всех параметров сборки в единый файл конфигурации.

Прощание с svelte.config.js: единый центр управления

Исторически SvelteKit зарождался в эпоху экспериментов с бандлерами, из-за чего настройки фреймворка жили отдельно от сборщика Vite. Это создавало постоянную рассинхронизацию: плагины не могли синхронно считывать настройки пререндеринга, а типизация конфигурации требовала дополнительных определений JSDoc.

В SvelteKit 3.0 файл svelte.config.js признан устаревшим и полностью удален. Теперь все параметры фреймворка — выбор серверного адаптера (Node, Cloudflare, Vercel), пути пререндеринга и директории кэша — передаются непосредственно в плагин sveltekit() внутри файла vite.config.ts. Это упростило пайплайн сборки: сборщик и мета-фреймворк стали единым целым.

Стандарт #lib: почему нативные субпути победили кастомные алиасы

Второе заметное изменение затрагивает каждый файл проекта. Популярный псевдоним $lib, использовавшийся для импорта внутренних модулей, уступил место официальному стандарту Node.js Subpath Imports под префиксом #lib.

Спецификация субпутей официально поддерживается средой Node.js через секцию "imports" в файле package.json. В отличие от кастомных алиасов, импорты с решеткой работают на уровне платформы:

• Инструменты статического анализа (ESLint, Biome) и тестовые фреймворки (Vitest) понимают такие пути нативно без специальных плагинов резолвинга.
• Спецификация SvelteKit 3.0 требует обязательного указания расширений файлов (.svelte, .ts, .js). Это исключает дорогостоящие проверки файловой системы на каждом импорте и ускоряет компиляцию больших проектов.

Сквозной сценарий: от централизованной конфигурации до чистых импортов

Централизация настроек делает кодовую базу компактной и наглядной. Все параметры проекта теперь собираются в одном файле vite.config.ts:

// vite.config.ts - единая конфигурация сборки и SSR в SvelteKit 3.0
import { sveltekit } from '@sveltejs/kit/vite'
import { defineConfig } from 'vite'
import adapter from '@sveltejs/adapter-node'

export default defineConfig({
  plugins: [
    sveltekit({
      adapter: adapter({ out: 'build' }),
      prerender: {
        entries: ['*']
      }
    })
  ]
})

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

// src/routes/+page.svelte - использование стандартных субпутей Node.js
<script lang="ts">
  // Было в версии 2: import Navigation from '$lib/Navigation'
  // Стало в версии 3: явный префикс #lib и обязательное расширение
  import Navigation from '#lib/components/Navigation.svelte'
  import { formatCurrency } from '#lib/utils/formatters.js'

  let { data } = $props()
</script>

<Navigation title="Панель управления" />

Для перевода существующих проектов команда выпустила утилиту миграции npx sv migrate sveltekit-3 --tasks all --confirm. Она автоматически анализирует синтаксическое дерево (AST) проекта, переносит настройки в vite.config.ts, заменяет импорты $lib на #lib и формирует список задач для ручной проверки.

Границы применения и инженерный вердикт

SvelteKit 3.0 — это стабильный релиз (General Availability), окончательно цементирующий союз со сборщиком Vite и реактивностью Svelte 5 (Runes). Однако разработчикам крупных enterprise-проектов стоит учитывать ломающие изменения: кастомные плагины, завязанные на старый объект config.kit, потребуют обновления. Механизм удаленных серверных функций (Remote Functions) пока отложен до стабилизации асинхронного режима Async Svelte.

Релиз демонстрирует зрелость экосистемы: вместо изобретения собственных закрытых стандартов команда Svelte последовательно внедряет спецификации платформы, делая разработку быстрее, строже и приятнее.