The SvelteKit 3 Release Candidate is here

SvelteKit 3 is now in the Release Candidate phase. If all goes well — meaning that people like you try it out and find that it works as expected — we will follow it up with a stable release in the near future, with no further breaking changes.

But there are some breaking changes since SvelteKit 2. We’re taking advantage of this release to prune some of the weeds in the codebase and lay the groundwork for SvelteKit’s continued evolution, more on which below.

To migrate an existing app, you can use the next version of sv migrate:

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

This will automatically migrate as much of your code as possible. For everything else, it will generate a TODO list for you (or your clanker of choice) to work through. Wherever possible, SvelteKit will print useful diagnostic warnings and errors if you try to run code that hasn’t yet been updated.

To create a new app, run sv create:

npx sv@next create my-new-app

What’s changed?

For the full list of changes, consult the migration guide over on next.svelte.dev which is where the SvelteKit 3 documentation will live until the stable release. Most changes are fairly minor, but a few are worth calling out:

Configuration now lives in vite.config.ts

Previously, you would configure SvelteKit via a svelte.config.js file. This turned out to be limiting: it’s useful for the Vite plugin to have access to your config immediately rather than having to go through an asynchronous resolution process (which can’t begin until after we’ve resolved the entire Vite config, because tools like Vitest may run with a current working directory that isn’t the project root), and after all why wouldn’t we put the config in one place rather than two?

The $lib alias is now #lib

In SvelteKit 2, you would put shared code in src/lib and import it via a $lib alias. This is nicer than importing from ../../../../somewhere, which is what inevitably happens in larger codebases.

But in modern projects, aliases are unnecessary, because we have something better: subpath imports. This Node feature is natively supported by tools like Vite and TypeScript, and it means we can delete the code that previously coordinated between them. There is one small gotcha: Node and TypeScript require that your subpath imports be unambiguous — instead of importing from #lib/foo, you will need to import from #lib/foo.ts or #lib/foo/index.ts.

TypeScript configuration got simpler

In SvelteKit 2, your tsconfig.json needed to extend the somewhat scruffy-looking ./.svelte-kit/tsconfig.json. In SvelteKit 3, you extend $app/tsconfig instead. This generated config file is written to node_modules/$app and contains configuration that is specific to your app. While it’s simpler than the SvelteKit 2 version (we no longer need to add the $lib alias to "paths", for example) it also includes more recommended compiler options, which means you can likely delete your own compilerOptions unless you have esoteric requirements.

You should explicitly specify your include and exclude arrays, and the latter should include your service worker. Speaking of which:

Service workers got a facelift

Using service workers is nicer in SvelteKit 3. Instead of the weird $service-worker module, which exposed the necessary tools to perform offline caching (for example), you can now just import those things from $app/env, $app/paths and the new $app/manifest module like in every other part of your app. You can also import self from $app/service-worker to get accurate typings for fetch events and so on, provided you create a tsconfig.json alongside your service worker that extends $app/tsconfig/service-worker.

In future, we may expose helper functions for different caching strategies, so that it’s easier to build things like offline-friendly PWAs without running into barbed wire.

Environment variables are more powerful

SvelteKit already had arguably the most sophisticated and flexible environment variable handling of any framework. SvelteKit 3 takes it a step further with the explicit environment variables feature, which are no longer behind an experimental flag. The gist is that you define which environment variables your app depends on, in src/env.ts, and specify if they should be publicly available (in which case you can import them into code that will run in the client) and whether they should be resolved at build time (in which case they can be used for optimizations like dead code elimination) or when the app boots up. You can also use Standard Schema libraries to validate your environment variables.

In exchange, you get effortless type-safe, secure, validated environment variables that can be auto-imported when you need them.

Error handling is way better

SvelteKit 2 was constrained by its support for Svelte 4, which didn’t have a concept of error boundaries. This meant that we could only display your +error.svelte components when errors occurred during load, not render. SvelteKit 3 requires Svelte 5, which means error handling can be made much more comprehensive and consistent.

Another change is that all errors are piped through your handleError logic, including the ones you deliberately created with error(...) which were previously ignored on the assumption that you’d already done something with them. This gives you more flexibility with less hoop-jumping.

Oh, and we apply sourcemaps to stack traces now. No biggie. (It’ll take a minute before every adapter can display properly sourcemapped stack traces in production, but this is the necessary first step.)

Shallow routing now happens with goto

Instead of using pushState and replaceState to use shallow routing, you now use goto with the shallow: true option. Shallow navigations now trigger beforeNavigate etc, and you can persist page state across a reload with persistState: true.

Vite 8: Rolldown, and the Environment API

SvelteKit 2 supported Vite 8, but SvelteKit 3 requires it. This means you get faster builds thanks to Rolldown.

We’ve also adopted the Vite Environment API, which simplifies some of our build logic. One thing we don’t support is FetchableDevEnvironment — we tried to make this work, but ulimately concluded that it forces frameworks to absorb too much complexity. We think the problems it aims to solve (most notably, providing access to Cloudflare Workers bindings during local development) can be addressed in other ways, which we’re actively exploring.

Remote functions

If you’ve been following SvelteKit’s development over the last year, you’ve likely encountered remote functions. This, alongside async Svelte, is our vision for how client-server communication should be handled.

We’re unreasonably excited about remote functions and can’t wait to use them everywhere. Frankly, they make everything else look a bit clunky, including SvelteKit’s load functions and actions.

For now, though, they remain behind an experimental flag as we iron out the last few kinks.

Send us your feedback

As ever, we rely on your thoughts and your bug reports: if you have the opportunity to upgrade your apps and test out the new stuff, we and the rest of the Svelte community will be in your debt. Thank you!