Aller au contenu

Le média des artisans du web vendredi 2 octobre 2026

Front-end

SvelteKit 3.0 est disponible en version stable

SvelteKit 3.0 a quitté le statut de release candidate le 1er octobre 2026, avec son lot de ruptures annoncées depuis l'été : Node 22.17, TypeScript 6 et Vite 8 deviennent incontournables, et l'alias $lib disparaît au profit de #lib.

SvelteKit 3.0 est publié sur le registre npm depuis le 1er octobre 2026, après plusieurs semaines de release candidate suivies sur mail-studio.com. La version stable confirme l’ensemble des ruptures annoncées pendant la phase de test : nouveaux prérequis d’environnement, réorganisation des modules internes et retrait de plusieurs API historiques. Pour les équipes qui géraient encore un projet sur SvelteKit 2, la fenêtre de migration s’ouvre désormais pour de bon.

Une sortie qui referme le cycle de la release candidate

La release candidate couverte fin août annonçait déjà l’essentiel : bascule de la configuration vers Vite, remplacement de l’alias $lib, et exigence d’une base technique plus récente. La version stable ne modifie pas cette trajectoire, elle la fige. Aucun délai de grâce supplémentaire n’est prévu pour les API supprimées.

Les prérequis qui changent

Le socle technique minimal grimpe sur plusieurs fronts à la fois, ce qui impose de vérifier l’ensemble de la chaîne d’outillage avant de lancer une migration.

PrérequisSvelteKit 2.xSvelteKit 3.0
Node.js18.13 ou supérieur22.17 ou supérieur
TypeScript5.x6.0 ou supérieur
Vite5.x ou 6.x8.0.12 ou supérieur
Svelte4.x ou 5.x5.56.4 ou supérieur
Fichier de configurationsvelte.config.jsvite.config.ts

Le relèvement vers TypeScript 6 rejoint une tendance plus large de l’écosystème JavaScript, où les frameworks cessent progressivement de garantir la compatibilité avec les versions de TypeScript sorties depuis plus d’un an.

Des imports à corriger dans le code existant

Le module $app/stores est retiré, au profit de $app/state qui s’appuie sur les runes de Svelte 5. L’alias $lib, utilisé dans la quasi-totalité des projets SvelteKit, est remplacé par l’export de sous-chemin #lib.

- import { page } from '$app/stores';
+ import { page } from '$app/state';

- import Button from '$lib/components/Button.svelte';
+ import Button from '#lib/components/Button.svelte';

Un outil de migration pour absorber l’essentiel

L’équipe Svelte fournit une commande de migration automatisée, capable de traiter la majorité des changements mécaniques (imports, configuration, options renommées) sans intervention manuelle complète sur chaque fichier.

npx sv@next migrate sveltekit-3 --tasks all --confirm

Le résultat reste à relire : les changements de comportement, comme la valeur par défaut du chemin de cookie désormais fixée à / ou la fusion des options noScroll et keepFocus en un unique paramètre reset, ne sont pas toujours détectables par un simple remplacement de texte.

SvelteKit 3.0 referme un cycle de release candidate entamé à la fin de l’été, sans étape de transition supplémentaire pour les projets qui s’appuyaient encore sur $app/stores.

Les projets encore sur Node 20 LTS doivent planifier une mise à niveau du runtime avant toute tentative de migration : SvelteKit 3.0 refuse de démarrer sous Node 22.17. Les pipelines d’intégration continue figés sur une image Node ancienne sont le piège le plus fréquent signalé par les premiers retours de migration.

Ce qu’il faut retenir

SvelteKit 3.0 formalise une modernisation déjà annoncée : configuration centrée sur Vite, imports réorganisés, et un socle technique aligné sur les versions récentes de Node, TypeScript et Vite. La commande sv migrate traite le gros du travail mécanique, mais une relecture manuelle reste nécessaire sur les comportements modifiés, en particulier autour de la navigation et des cookies.

La bascule de la configuration vers vite.config.ts est le changement qui me semble le plus structurant, davantage que le retrait de $app/stores dont la migration est quasi mécanique. Elle acte que SvelteKit n’a plus de système de configuration propre, et s’en remet entièrement à celui de Vite — un choix cohérent avec le reste de l’écosystème, mais qui mérite d’être anticipé sur les gros monorepos où plusieurs plugins Vite se superposent déjà. Sur les projets outillés en CLI, mieux vaut tester la migration sur une branche dédiée avant de la lancer sur le dépôt principal. — Simon Janvier

Pour aller plus loin : notes de version complètes de SvelteKit sur GitHub.

Partager LinkedIn Bluesky Hacker News E-mail

À lire aussi