Das Svelte-Team hat SvelteKit 3 Anfang September 2026 in den Release Candidate überführt, wenige Tage nach dem Erscheinen von Svelte 5.57. Die Hauptversion des Meta-Frameworks ordnet ihre Vite-Integration neu, übernimmt die Subpath-Imports von Node anstelle des $lib-Alias und übergibt die Migration einem neuen Kommandozeilenwerkzeug. Festgeschrieben ist noch nichts, doch der Aktualisierungspfad ist inzwischen klar.
Ein Release Candidate, noch keine stabile Version
SvelteKit 3 reifte über aufeinanderfolgende Vorabversionen, von 3.0.0-next.17 bis 3.0.0-next.25 zum Zeitpunkt der Ankündigung des Release Candidate. Dieser Status signalisiert eine eingefrorene API-Oberfläche: Das Team wartet vor allem auf Rückmeldungen aus der Praxis vor der finalen Version und sollte keine weiteren brechenden Änderungen einführen. Produktionsprojekte fahren daher besser, wenn sie den Wechsel auf einem eigenen Branch testen, statt überhastet zu aktualisieren.
Das Vite-Plugin im Zentrum der Überarbeitung
Die strukturelle Neuerung dieser Version ist die Neufassung der Vite-Plugin-Architektur. SvelteKit orientiert sich an der jüngsten Entwicklung von Vite und schärft die Grenze zwischen Framework und Bundler, mit überarbeiteten Formular-Actions und mehreren Verfeinerungen des Routings als Ergebnis. Dieser Schritt hin zu moderneren Grundlagen setzt einen Grundtrend im Front-End-Werkzeug fort.
Von $lib zu #lib: interne Imports übernehmen eine Node-Konvention
In einem mit dem neuen Werkzeug erstellten Projekt laufen interne Imports nicht mehr über den hauseigenen Alias $lib, sondern über #lib, das sich auf das Feld imports in package.json stützt, also auf die Standard-Subpath-Imports von Node.
{
"imports": {
"#lib/*": "./src/lib/*.js"
}
}
In der Praxis wechselt ein Import das Präfix, nicht das Ziel:
- import { formatDate } from '$lib/utils';
+ import { formatDate } from '#lib/utils';
Der Vorteil liegt darin, sich auf eine Konvention zu stützen, die Node, Editoren und Testwerkzeuge nativ verstehen, ohne einen framework-eigenen Mechanismus, der auf beiden Seiten konfiguriert werden müsste.
Svelte 5.57 erscheint parallel
Im selben Zeitraum veröffentlicht, ergänzt Svelte 5.57 mehrere erwartete Primitive, ohne bestehenden Code zu brechen.
| Neuerung | Was sie bringt |
|---|---|
SvelteMap.getOrInsert und getOrInsertComputed | Einen Schlüssel lesen oder in einem Schritt initialisieren, auf einer reaktiven Map |
Dritter Wert has von createContext() | Prüfen, ob ein Kontext gesetzt wurde, bevor man ihn zu lesen versucht |
<select defaultValue> | Stellt den gewählten Wert beim Zurücksetzen eines Formulars wieder her |
Von svelte/server exportierte Typen | RenderOutput, SyncRenderOutput, Csp und Sha256Source, nützlich für das Server-Rendering und CSP-Richtlinien |
Die Migration übernimmt der sv-Befehl
Das Werkzeug sv erreicht die Version 1.0.0-next.0 und setzt auf eine aufgabenbasierte Migration. Ein eigener Befehl wendet die für SvelteKit 3 spezifischen Umstellungen an, darunter das Ersetzen von $lib durch #lib in neuen Projekten.
npx sv migrate sveltekit-3
Dieser aufgabenbasierte Ansatz entspricht der Logik von Kommandozeilenwerkzeugen im Allgemeinen: gezielte, wiederholbare Vorgänge, deren Ergebnis sich in einem Diff prüfen lässt, bevor es übernommen wird.
Zu beachten: Ein Release Candidate ist keine Produktionsversion. Es bleibt ratsam, die genaue Vorabversion im Lockfile festzuschreiben, die Testsuite nach der Migration erneut auszuführen und Vite-Plugins von Drittanbietern im Blick zu behalten, von denen einige noch die alte Architektur voraussetzen.
Indem es seine API einfriert und seine Imports auf Node standardisiert, setzt SvelteKit 3 auf Vorhersehbarkeit statt auf spektakuläre Neuerungen.
Das Wichtigste
Der Release Candidate markiert den Eintritt von SvelteKit 3 in die Zielgerade. Die beiden Änderungen, auf die man sich vorbereiten sollte, sind die Überarbeitung des Vite-Plugins und der Wechsel von $lib zu #lib. Der Befehl sv automatisiert den Großteil der Aktualisierung, während Svelte 5.57 parallel willkommene API-Primitive beisteuert. Bis die finale Version erscheint, bleibt das Testen auf einem eigenen Branch der richtige Weg.
Der Wechsel von $lib zu #lib wirkt kosmetisch und erweist sich in der Praxis als sehr praktisch: Ein von Node nativ verstandener Import ist ein Sonderfall weniger, der sich über Editor, Bundler und Tests verteilt. Aus meiner Sicht hat sich die Migration über sv bei aktuellen Projekten als zuverlässig erwiesen, sofern man sie auf einem sauberen Repository ausführt und den Diff vor der Übernahme prüft. — Simon Janvier
Quelle: What’s new in Svelte: September 2026, im offiziellen Blog des Projekts.
