SvelteKit 3.0 has been available on the npm registry since October 1, 2026, after several weeks as a release candidate tracked here on mail-studio.com. The stable release confirms every breaking change flagged during the testing phase: new environment requirements, reorganized internal modules, and the removal of several long-standing APIs. For teams still running SvelteKit 2, the migration window is now open for good.
A release that closes out the candidate cycle
The release candidate covered here in late August already laid out the essentials: configuration moving into Vite, the $lib alias being replaced, and a higher minimum toolchain. The stable release does not change that trajectory, it locks it in. No additional grace period is planned for the removed APIs.
What the baseline requirements become
The minimum technical baseline moves on several fronts at once, which makes it worth auditing the full toolchain before starting a migration.
| Requirement | SvelteKit 2.x | SvelteKit 3.0 |
|---|---|---|
| Node.js | 18.13 or newer | 22.17 or newer |
| TypeScript | 5.x | 6.0 or newer |
| Vite | 5.x or 6.x | 8.0.12 or newer |
| Svelte | 4.x or 5.x | 5.56.4 or newer |
| Config file | svelte.config.js | vite.config.ts |
The bump to TypeScript 6 fits a broader pattern across the JavaScript ecosystem, where frameworks increasingly stop guaranteeing compatibility with TypeScript releases older than a year.
Imports that need fixing in existing code
The $app/stores module is removed entirely, in favor of $app/state, which is built on Svelte 5 runes. The $lib alias, used in nearly every SvelteKit project, is replaced by the #lib subpath export.
- import { page } from '$app/stores';
+ import { page } from '$app/state';
- import Button from '$lib/components/Button.svelte';
+ import Button from '#lib/components/Button.svelte';A migration tool to handle most of the work
The Svelte team ships an automated migration command that handles most of the mechanical changes (imports, config, renamed options) without requiring manual edits across every file.
npx sv@next migrate sveltekit-3 --tasks all --confirmThe output still needs a review pass: behavioral changes, such as the cookie path now defaulting to / or the merge of the noScroll and keepFocus options into a single reset parameter, are not always caught by a plain text replacement.
SvelteKit 3.0 closes out a release-candidate cycle that began in late summer, with no further transition step for projects still relying on $app/stores.
Projects still running Node 20 LTS need to schedule a runtime upgrade before attempting the migration: SvelteKit 3.0 refuses to start under Node 22.17. CI pipelines pinned to an older Node image are the most frequently reported pitfall from early migrations.
Key takeaways
SvelteKit 3.0 formalizes a modernization that was already announced: configuration centered on Vite, reorganized imports, and a baseline aligned with recent Node, TypeScript, and Vite releases. The sv migrate command handles most of the mechanical work, but a manual review remains necessary for behavioral changes, particularly around navigation and cookies.
The move of configuration into vite.config.ts strikes me as the more structural change here, more so than dropping $app/stores, whose migration is nearly mechanical. It signals that SvelteKit no longer owns its own configuration layer and defers entirely to Vite’s — a sensible call given the rest of the ecosystem, but one worth planning for on large monorepos where several Vite plugins already overlap. On projects already driven from the command line, it is worth testing the migration on a dedicated branch before running it against the main repository. — Simon Janvier
Further reading: full SvelteKit release notes on GitHub.
