SvelteKit 3 ist in die Release-Candidate-Phase eingetreten. Das Team stellt eine stabile Version „in naher Zukunft, ohne weitere Breaking Changes“ in Aussicht, womit dieser RC die Grundlage bildet, gegen die Projekte ihr Upgrade planen können. Es ist mehr als ein Frühjahrsputz: Die Konfiguration wechselt die Datei, Remote-Funktionen ordnen die Client-Server-Kommunikation neu, und ein Migrationsbefehl übernimmt den Großteil der mechanischen Arbeit.
Die Konfiguration wandert nach Vite
Die sichtbarste Änderung betrifft, wie ein Projekt konfiguriert wird. Die Konfiguration verlässt svelte.config.js zugunsten von vite.config.ts: SvelteKit 3 stützt sich nun vollständig auf Vite 8, das es voraussetzt, und auf Svelte 5. Nebenbei weicht der bisherige Alias $lib den Subpfad-Importen #lib, und die TypeScript-Einrichtung wird vereinfacht, indem sie $app/tsconfig erweitert statt einer umfangreichen generierten Datei.
Der Wechsel bringt SvelteKit auf eine Linie mit den Werkzeugen, die die meisten modernen JavaScript-Projekte ohnehin nutzen. Er hat seinen Preis: Bestehende Konfigurationsdateien müssen neu geschrieben werden, und Integrationen, die svelte.config.js lasen, müssen sich anpassen.
Remote-Funktionen, das Herz der Version
Das Merkmal, das diese Version prägt, hat einen Namen: Remote-Funktionen. Sie erlauben es, Servercode direkt aus einer Komponente aufzurufen, mit durchgehender Typinferenz — ohne +server.ts-Datei, ohne von Hand verdrahtete fetch-Aufrufe und ohne die Typen von Anfrage und Antwort manuell synchron zu halten. Vier Primitive decken die üblichen Fälle ab: query zum Lesen von Daten, form für Formular-Übermittlungen, command für Mutationen und prerender für zur Bauzeit berechnete Werte.
// data.remote.ts
import { query } from '$app/server';
export const listArticles = query(async () => {
// exécuté sur le serveur, typé jusque dans le composant
return await db.articles.findMany();
});
In der Komponente wird die Funktion wie jede asynchrone Funktion importiert und abgewartet; die Netzwerkgrenze wird damit zum Implementierungsdetail statt zu einem zu pflegenden Vertrag.
Indem SvelteKit 3 die
+server.ts-Datei aus einem einfachen Datenabruf entfernt, rückt es den Servercode näher an die Komponente, die ihn nutzt.
Aufgepasst. Remote-Funktionen bleiben in diesem RC hinter einem experimentellen Flag. Sie skizzieren die Richtung des Frameworks, doch die API kann sich noch ändern: Sie heute in Produktion zu bringen, heißt Anpassungen in kommenden Versionen in Kauf zu nehmen.
Flaches Routing, Fehler und Tracing
Mehrere tieferliegende APIs werden überarbeitet. Flaches Routing ist nun in goto() integriert, ohne separates Modul. Die Signatur von error() ändert sich: Die Nachricht wird zu einem vollwertigen Argument. invalidateAll() wird zu refreshAll() umbenannt, der alte Name bleibt für den Übergang veraltet.
Zwei neue Module kommen hinzu. $app/manifest stellt zur Laufzeit Informationen über Assets, vorgerenderte Seiten und Routen bereit; $app/service-worker, ergänzt durch die nun in diesem Kontext verfügbaren $app/paths, verbessert das Schreiben von Service Workern. Das Tracing verlässt den experimentellen Namensraum, und Produktions-Sourcemaps werden unterstützt, auch um einen Stacktrace mit seinem Quellcode zu verknüpfen.
Migration: ein Werkzeug, einige Brüche
SvelteKit liefert einen Migrationsbefehl, der den Großteil der Arbeit übernimmt und die von Hand zu erledigenden Punkte auflistet. Ein neues Projekt wird mit derselben Werkzeugfamilie in ihrer „next“-Version aufgesetzt.
# migrer un projet existant
npx sv@next migrate sveltekit-3 --tasks all --confirm
# démarrer un nouveau projet
npx sv@next create my-new-app
Die folgende Tabelle fasst die strukturellen Verschiebungen zusammen, die es einzuplanen gilt.
| Element | SvelteKit 2 | SvelteKit 3 |
|---|---|---|
| Konfigurationsdatei | svelte.config.js | vite.config.ts |
| Bibliotheks-Alias | $lib | #lib |
| Daten aktualisieren | invalidateAll() | refreshAll() |
| Vorausgesetzte Basis | Früheres Vite, Svelte 5 | Vite 8, Svelte 5 |
| Servercode aus einer Komponente | +server.ts + fetch | Remote-Funktionen (experimentell) |
Was bleibt
SvelteKit 3 ist keine kosmetische Überarbeitung: Die Verlagerung der Konfiguration nach Vite und die Umbenennung mehrerer APIs erzwingen eine Migration, die das eigens dafür gedachte Werkzeug glücklicherweise recht schmerzlos macht. Das eigentliche Versprechen liegt in den Remote-Funktionen, die die manuelle API-Schicht zwischen Server und Komponente verschwinden lassen wollen — doch sie bleiben experimentell, und genau sie gilt es bis zur stabilen Version im Auge zu behalten.
Ich habe SvelteKit in mehreren Kundenprojekten gerade wegen seiner Fähigkeit eingesetzt, Klempner-Code zu reduzieren. Remote-Funktionen gehen genau in diese Richtung: In einer Anwendung, in der ich ein Dutzend +server.ts-Routen und ihre Typen von Hand pflege, ist der Ersatz durch direkte, typisierte Aufrufe das Erste, was mich den RC ausprobieren lassen wollte. Ich bringe sie nicht in Produktion, solange sie das experimentelle Flag tragen, aber ich schreibe die Konfiguration schon jetzt um, um am Tag der stabilen Version bereit zu sein. — Simon Janvier
Zum Weiterlesen: die offizielle Ankündigung des Release Candidate, „The SvelteKit 3 Release Candidate is here“ im Svelte-Blog.
