SvelteKit 3 est entré en phase de release candidate. L’équipe annonce une version stable « dans un futur proche, sans nouvelle rupture », ce qui fait de cette RC le socle sur lequel les projets peuvent commencer à préparer leur montée de version. Le chantier ne se limite pas à un dépoussiérage : la configuration change de fichier, les fonctions distantes rebattent les cartes de la communication client-serveur, et une commande de migration prend en charge l’essentiel du travail mécanique.
Une configuration qui déménage dans Vite
Le changement le plus visible touche la manière dont un projet se configure. La configuration quitte svelte.config.js pour vite.config.ts : SvelteKit 3 s’appuie désormais pleinement sur Vite 8, qu’il requiert, et sur Svelte 5. Dans la foulée, l’alias historique $lib laisse place à des imports par sous-chemin #lib, et la configuration TypeScript se simplifie en étendant $app/tsconfig au lieu d’un fichier généré verbeux.
Cette bascule aligne SvelteKit sur l’outillage qu’utilisent déjà la plupart des projets JavaScript modernes. Elle a un coût : les fichiers de configuration existants doivent être réécrits, et les intégrations qui lisaient svelte.config.js devront s’adapter.
Les fonctions distantes, cœur de la nouveauté
La fonctionnalité qui structure cette version porte un nom : les fonctions distantes. Elles permettent d’appeler du code serveur directement depuis un composant, avec une inférence de types de bout en bout — sans écrire de fichier +server.ts, sans câbler manuellement les appels fetch, et sans maintenir à la main la cohérence entre les types de la requête et ceux de la réponse. Quatre primitives couvrent les usages courants : query pour lire des données, form pour les soumissions de formulaire, command pour les mutations, et prerender pour les valeurs calculées à la compilation.
// 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();
});
Côté composant, la fonction s’importe et s’appelle comme n’importe quelle fonction asynchrone, la frontière réseau devenant un détail d’implémentation plutôt qu’un contrat à entretenir.
En retirant le fichier
+server.tsd’une simple lecture de données, SvelteKit 3 rapproche le code serveur du composant qui le consomme.
Point de vigilance. Les fonctions distantes restent derrière un drapeau expérimental dans cette RC. Elles esquissent la direction prise par le framework, mais l’API peut encore bouger : les mettre en production aujourd’hui revient à accepter des ajustements lors des prochaines versions.
Routage superficiel, erreurs et traçage
Plusieurs API de plus bas niveau sont revues. Le routage superficiel est désormais intégré à goto(), sans passer par un module séparé. La signature de error() évolue : le message devient un argument à part entière. La fonction invalidateAll() est renommée refreshAll(), l’ancienne restant dépréciée le temps de la transition.
Deux nouveaux modules font leur apparition. $app/manifest expose à l’exécution des informations sur les ressources, les pages prérendues et les routes ; $app/service-worker, complété par la disponibilité de $app/paths dans ce contexte, améliore l’écriture des service workers. Enfin, le traçage sort du domaine expérimental et les sourcemaps de production sont prises en charge, y compris pour rattacher une pile d’appels à son code source.
Migration : un outil, quelques ruptures
SvelteKit fournit une commande de migration qui prend en charge la majeure partie du travail et dresse la liste des points à traiter manuellement. Un projet neuf s’échafaude avec la même famille d’outils en version « next ».
# 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
Le tableau ci-dessous résume les déplacements structurants à anticiper.
| Élément | SvelteKit 2 | SvelteKit 3 |
|---|---|---|
| Fichier de configuration | svelte.config.js | vite.config.ts |
| Alias de bibliothèque | $lib | #lib |
| Rafraîchissement des données | invalidateAll() | refreshAll() |
| Socle requis | Vite antérieur, Svelte 5 | Vite 8, Svelte 5 |
| Code serveur depuis un composant | +server.ts + fetch | fonctions distantes (expérimental) |
Ce qu’il faut retenir
SvelteKit 3 n’est pas une révision cosmétique : le déplacement de la configuration vers Vite et le renommage de plusieurs API imposent une migration, que l’outil dédié rend heureusement peu douloureuse. La vraie promesse tient dans les fonctions distantes, qui visent à faire disparaître la couche d’API manuelle entre le serveur et le composant — mais elles restent expérimentales, et c’est sur elles qu’il faudra garder un œil d’ici la version stable.
J’ai adopté SvelteKit sur plusieurs projets clients précisément pour sa capacité à réduire le code de plomberie. Les fonctions distantes vont exactement dans ce sens : sur une application où je maintiens à la main une douzaine de routes +server.ts et leurs types, la perspective de les remplacer par des appels typés directs est la première chose qui m’a donné envie de tester la RC. Je ne les mettrai pas en production tant qu’elles portent le drapeau expérimental, mais je commence dès maintenant à réécrire les configurations pour être prêt le jour de la stable. — Simon Janvier
Pour aller plus loin : l’annonce officielle de la release candidate, « The SvelteKit 3 Release Candidate is here » sur le blog Svelte.
