SvelteKit 3.0 steht seit dem 1. Oktober 2026 im npm-Registry bereit, nach mehreren Wochen als Release Candidate, die hier auf mail-studio.com begleitet wurden. Die stabile Version bestätigt sämtliche Breaking Changes, die während der Testphase angekündigt wurden: neue Umgebungsanforderungen, eine Neuordnung der internen Module und die Entfernung mehrerer altbekannter APIs. Teams, die noch ein Projekt auf SvelteKit 2 betreiben, steht das Migrationsfenster nun endgültig offen.
Ein Release, das den Release-Candidate-Zyklus abschließt
Der Ende August hier behandelte Release Candidate hatte das Wesentliche bereits angekündigt: Die Konfiguration wandert nach Vite, der Alias $lib wird ersetzt, und der technische Mindeststandard steigt. Die stabile Version ändert diese Richtung nicht, sie zementiert sie. Für die entfernten APIs ist keine zusätzliche Übergangsfrist vorgesehen.
Diese Mindestanforderungen ändern sich
Der technische Mindeststandard steigt an mehreren Stellen gleichzeitig, weshalb sich eine Prüfung der gesamten Toolchain vor dem Start einer Migration lohnt.
| Anforderung | SvelteKit 2.x | SvelteKit 3.0 |
|---|---|---|
| Node.js | 18.13 oder neuer | 22.17 oder neuer |
| TypeScript | 5.x | 6.0 oder neuer |
| Vite | 5.x oder 6.x | 8.0.12 oder neuer |
| Svelte | 4.x oder 5.x | 5.56.4 oder neuer |
| Konfigurationsdatei | svelte.config.js | vite.config.ts |
Der Sprung auf TypeScript 6 reiht sich in einen breiteren Trend im JavaScript-Ökosystem ein, in dem Frameworks zunehmend keine Kompatibilität mehr mit mehr als ein Jahr alten TypeScript-Versionen garantieren.
Imports, die im bestehenden Code korrigiert werden müssen
Das Modul $app/stores wird vollständig entfernt, zugunsten von $app/state, das auf den Runes von Svelte 5 aufbaut. Der in nahezu jedem SvelteKit-Projekt genutzte Alias $lib wird durch den Subpath-Export #lib ersetzt.
- import { page } from '$app/stores';
+ import { page } from '$app/state';
- import Button from '$lib/components/Button.svelte';
+ import Button from '#lib/components/Button.svelte';Ein Migrationswerkzeug für den Großteil der Arbeit
Das Svelte-Team stellt einen automatisierten Migrationsbefehl bereit, der die meisten mechanischen Änderungen (Imports, Konfiguration, umbenannte Optionen) übernimmt, ohne dass jede Datei manuell bearbeitet werden muss.
npx sv@next migrate sveltekit-3 --tasks all --confirmDas Ergebnis muss trotzdem durchgesehen werden: Verhaltensänderungen, etwa der nun standardmäßig auf / gesetzte Cookie-Pfad oder die Zusammenführung der Optionen noScroll und keepFocus zu einem einzigen Parameter reset, lassen sich nicht immer durch einen reinen Textersatz erkennen.
SvelteKit 3.0 schließt einen Release-Candidate-Zyklus ab, der Ende des Sommers begann, ohne weitere Übergangsstufe für Projekte, die noch auf $app/stores setzten.
Projekte, die noch auf Node 20 LTS laufen, müssen ein Runtime-Upgrade einplanen, bevor sie die Migration angehen: SvelteKit 3.0 verweigert den Start unter Node 22.17. CI-Pipelines, die auf einem älteren Node-Image festgelegt sind, sind die am häufigsten gemeldete Falle bei den ersten Migrationen.
Das Wichtigste in Kürze
SvelteKit 3.0 besiegelt eine bereits angekündigte Modernisierung: eine auf Vite zentrierte Konfiguration, neu geordnete Imports und einen Mindeststandard, der an aktuelle Node-, TypeScript- und Vite-Versionen angeglichen ist. Der Befehl sv migrate übernimmt den Großteil der mechanischen Arbeit, eine manuelle Prüfung bleibt jedoch bei Verhaltensänderungen nötig, insbesondere rund um Navigation und Cookies.
Der Umzug der Konfiguration nach vite.config.ts erscheint mir als die strukturell bedeutsamere Änderung, mehr noch als die Entfernung von $app/stores, deren Migration fast mechanisch verläuft. Sie macht deutlich, dass SvelteKit kein eigenes Konfigurationssystem mehr besitzt und sich vollständig auf das von Vite verlässt — eine nachvollziehbare Entscheidung angesichts des restlichen Ökosystems, die aber in großen Monorepos mit bereits überlappenden Vite-Plugins vorausschauend geplant werden sollte. Bei Projekten, die bereits von der Kommandozeile aus gesteuert werden, lohnt es sich, die Migration zunächst auf einem eigenen Branch zu testen, bevor sie auf das Hauptrepository angewendet wird. — Simon Janvier
Zum Weiterlesen: vollständige SvelteKit-Release-Notes auf GitHub.
