L’équipe Svelte a fait passer SvelteKit 3 en Release Candidate début septembre 2026, quelques jours après la sortie de Svelte 5.57. La version majeure du méta-framework réorganise son intégration à Vite, adopte les subpath imports de Node pour remplacer l’alias $lib et confie la mise à jour à un nouvel outil en ligne de commande. Rien n’est encore figé, mais le chemin de migration est désormais lisible.
Une Release Candidate, pas encore une version stable
SvelteKit 3 a mûri au fil de préversions successives, de 3.0.0-next.17 à 3.0.0-next.25 au moment où la Release Candidate a été annoncée. Ce statut signale que la surface d’API est gelée : l’équipe attend surtout des retours de terrain avant la publication finale, et n’introduira normalement plus de changement cassant. Les projets en production ont donc intérêt à tester la bascule sur une branche dédiée, à l’image des équipes qui ont récemment adopté htmx 4.0 et son héritage d’attributs explicite, plutôt que de mettre à jour dans la précipitation.
Le plugin Vite au cœur de la refonte
La nouveauté structurante de cette version est la réécriture de l’architecture du plugin Vite. SvelteKit s’aligne sur les évolutions récentes de Vite et clarifie la frontière entre le framework et le bundler, avec à la clé des actions de formulaire retravaillées et plusieurs ajustements du routage. Cette bascule vers des fondations plus modernes prolonge une tendance de fond dans l’outillage front-end, déjà visible avec le passage de TypeScript à un compilateur natif.
De $lib à #lib : les imports internes adoptent une convention Node
Dans un projet créé avec le nouvel outillage, les imports internes ne passent plus par l’alias maison $lib mais par #lib, qui repose sur le champ imports de package.json, c’est-à-dire les subpath imports standard de Node.
{
"imports": {
"#lib/*": "./src/lib/*.js"
}
}
Concrètement, un import change de préfixe sans changer de cible :
- import { formatDate } from '$lib/utils';
+ import { formatDate } from '#lib/utils';
L’intérêt est de s’appuyer sur une convention comprise nativement par Node, les éditeurs et les outils de test, sans mécanisme propre au framework à configurer de part et d’autre.
Svelte 5.57 accompagne la sortie
Publiée dans la foulée, la version 5.57 de Svelte ajoute plusieurs primitives attendues, sans rupture pour le code existant.
| Ajout | Ce qu’il apporte |
|---|---|
SvelteMap.getOrInsert et getOrInsertComputed | Lire une clé ou l’initialiser en une seule opération sur une Map réactive |
Troisième valeur has de createContext() | Vérifier qu’un contexte a bien été défini avant de tenter de le lire |
<select defaultValue> | Rétablit la valeur choisie lors d’une réinitialisation de formulaire |
Types exportés par svelte/server | RenderOutput, SyncRenderOutput, Csp et Sha256Source, utiles au rendu serveur et aux politiques CSP |
La migration confiée à la commande sv
L’outil sv atteint la version 1.0.0-next.0 et adopte une logique de migration par tâches. Une commande dédiée applique les transformations propres à SvelteKit 3, dont le remplacement de $lib par #lib dans les nouveaux projets.
npx sv migrate sveltekit-3
Cette approche par tâches rejoint la logique des outils en ligne de commande du développement web : des opérations ciblées, rejouables, dont le résultat se relit dans un diff avant d’être validé.
Point de vigilance : une Release Candidate n’est pas une version de production. Il reste prudent de figer la préversion exacte dans le lockfile, de rejouer la suite de tests après migration et de surveiller les plugins Vite tiers, dont certains supposent encore l’ancienne architecture.
En gelant son API et en standardisant ses imports sur Node, SvelteKit 3 mise sur la prévisibilité plutôt que sur la nouveauté spectaculaire.
Ce qu’il faut retenir
La Release Candidate marque l’entrée de SvelteKit 3 dans sa dernière ligne droite. Les deux changements à préparer sont la refonte du plugin Vite et le passage de $lib à #lib. La commande sv automatise l’essentiel de la mise à jour, tandis que Svelte 5.57 apporte en parallèle des ajouts d’API bienvenus. Tant que la version finale n’est pas publiée, tester sur une branche dédiée demeure la marche à suivre.
Le passage de $lib à #lib a tout du détail cosmétique et se révèle, à l’usage, très pratique : un import compris nativement par Node, c’est un cas particulier de moins à gérer côté éditeur, bundler et tests. De mon côté, la migration via sv s’est montrée fiable sur des projets récents, à condition de la lancer sur un dépôt propre et de relire le diff avant de valider. — Simon Janvier
Source : What’s new in Svelte: September 2026, sur le blog officiel du projet.
