SvelteKit 3 moves config into Vite and raises the floor to Node 22 and Vite 8, and the upgrade is a project, not a bump
SvelteKit 3 is out. Configuration moves into vite.config.ts, $lib becomes #lib, and the minimum stack jumps to Node 22.17, TypeScript 6, and Vite 8. A migration command does most of the work, but CSRF, cookie, and adapter changes still need a human eye.
SvelteKit 3.0 shipped on October 1, and the Svelte team describes it as the same framework with more polish, more type safety, and less junk. That framing is fair about the programming model, which barely moves. It undersells the upgrade itself. The new release raises the minimum stack, renames the framework’s most familiar import alias, and changes several security and routing defaults, so for most production apps moving to 3.0 looks less like a version bump and more like a small, scheduled project.
What changed in the framework
The headline change is where configuration lives. Project settings that used to sit in
svelte.config.js are now passed to the sveltekit plugin in vite.config.ts. InfoQ’s
coverage of the release candidate notes that this lets the Vite plugin read configuration
synchronously instead of waiting on an asynchronous resolution step, and that the move
began in the 2.x line before 3.0 made it the rule.
The second change is the one developers will notice in every file. The $lib alias is
replaced by #lib, which relies on Node’s standard subpath imports declared in
package.json rather than a SvelteKit-specific path mapping. Imports also need file
extensions, so $lib/foo becomes #lib/foo.js. InfoQ reported the change drew mixed
reactions from the community, with some developers warming to it once they saw it aligns
with a platform standard instead of framework magic.
Several older APIs are also gone. The $app/stores module is removed in favor of
$app/state, the $env/* modules are deprecated in favor of $app/env/private and
$app/env/public, and the $service-worker module is removed. For developers, the
practical point is that 3.0 assumes a fully Svelte 5 codebase; apps still leaning on
stores-era patterns have to finish that migration first.
The new floor
According to the migration guide, SvelteKit 3 requires Node 22.17, TypeScript 6, Svelte 5.57.1, and Vite 8.0.12. Each of those is a dependency decision in its own right. Teams on older Node runtimes in CI or on self-hosted servers, or on TypeScript 5 because of other tooling, will need to clear those upgrades before SvelteKit 3 is even an option.
Defaults that deserve a review
Some changes are easy to miss because the migration command may apply them without breaking the build:
- CSRF protection is always on. The deprecated
csrf.checkOriginoption is removed. Apps that disabled origin checks to accept cross-origin form posts must now list those hosts incsrf.trustedOrigins. - Cookie paths default to
/. A cookie set without an explicitpathnow applies site-wide rather than to the current request path, which can change how session and preference cookies scope. - Adapter changes.
adapter-vercelno longer supports theedgeruntime, andadapter-nodedrops theORIGINenvironment variable in favor ofpaths.originin the Vite config. Deployments that setORIGINin their hosting environment will need a config change, not just a dependency update.
Each of these sits in deployment or security behavior rather than in component code, which is where automated migrations are least likely to catch intent.
Migration in practice
The guide recommends upgrading to the latest 2.x release first, so the targeted
deprecation warnings surface problems before the major version does. From there, the team
ships a migration command, npx sv migrate sveltekit-3 --tasks all --confirm,
that rewrites as much of a codebase as it can and generates a TODO list for the rest. That
should handle the mechanical work: moving configuration, rewriting $lib imports, and
renaming modules. The judgment calls are the ones listed above, plus any hosting setup
that relied on the Vercel edge runtime.
One piece of the roadmap is still pending. Remote functions, the type-safe client to server call layer the team calls its top priority, are not production-ready in 3.0 because they depend on Async Svelte, which still sits behind an experimental flag. Teams waiting for that feature to stabilize can reasonably treat 3.0 as the foundation and plan around a later minor release.
What to watch
The next signals are how quickly the adapter ecosystem and popular Svelte libraries ship 3.0-compatible releases, and how much of a typical app the migration command actually covers outside the team’s own examples. For teams choosing a meta-framework today, the release makes SvelteKit’s direction clearer: closer to Vite and Node standards, with less framework-specific configuration to learn.