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!

The SvelteKit 3 preview lands with new $app modules, zero-config error props and refreshAll

The biggest news this month is the first @next releases of SvelteKit 3. Thirteen preview versions shipped in July: previewing new $app/manifest and $app/service-worker modules, improved API availability and type checking in service workers, tracing out of the experimental namespace, shallow routing baked into goto and a lot more. It's a prerelease, but it's worth trying out to see what's coming to SvelteKit!

Alongside the preview releases, the stable line kept moving with submitted on remote forms and a new home for defineEnvVars. The language tools also picked up zero-config +error.svelte props so error pages get their page and error types with no extra setup.

And, in case you missed it, Svelte Summit Ljubljana 2026 is happening November 19-20, with a workshop day on November 18, the day before the summit. Save the date!

What's new in SvelteKit

• Remote forms now expose a submitted property so you can react to the moment a form is submitted without waiting for the response (2.69.0, Docs, #14811)
• defineEnvVars has moved from @sveltejs/kit to @sveltejs/kit/env so environment helpers live in a dedicated subpath (2.70.0, Docs, #16378)

SvelteKit 3 preview

The next major version has landed in @next. Here are the highlights from 3.0.0-next.5 through 3.0.0-next.13 that you'll actually want to try out:

• Shallow routing is now built into goto via a new state option (with persistState: true to keep state across reloads), replacing pushState and replaceState (3.0.0-next.13, #16449)
• goto's noScroll and keepFocus options (and their matching data-sveltekit-* attributes) collapse into a single reset option (3.0.0-next.13, #16558)
• error(status, {...}) is deprecated in favor of error(status, message, {...}) so error messages are always required (3.0.0-next.13, #16540)
• refreshAll replaces invalidateAll, which is now deprecated (3.0.0-next.8, #16289)
• A new $app/manifest module exposes immutable, assets, prerendered and routes so you can introspect the build output at runtime (3.0.0-next.12, #16372)
• A new $app/service-worker module replaces the old $service-worker, and $app/paths is now importable inside service workers (3.0.0-next.12, #16458, #16441)
• SvelteKit now detects new deployments on data, remote and form action responses, on tab focus and on visibility change, with a default version.pollInterval of one hour (3.0.0-next.12, #16496)
• Sourcemaps are now supported in production builds (3.0.0-next.11, #16412)
• Tracing has moved out of the experimental namespace and the instrumentation flag has been removed (3.0.0-next.7, #16260)
• Form fields pick up a dirty() helper and remote forms get a new field.touched() for better validation UX (3.0.0-next.6, #16208, #14692)

Full preview details (including expected breaking changes) are in the SvelteKit 3 CHANGELOG.

For all the features and bugfixes across the stable line and adapters, check out the SvelteKit CHANGELOGs.

What's new in the Svelte CLI and Language Tools

• sv now picks the right package manager more reliably, with detection that respects the lockfile in nested workspaces ([email protected], #1190)
• Add-on authors can now call addOption during the setup phase to add options dynamically based on user choices ([email protected], #1042)
• The prettier add-on now formats every file it generates, not just the ones it touches ([email protected], #1192)
• The better-auth add-on has been bumped to Better Auth 1.6 and now uses the dedicated auth package ([email protected], #1058)
• sv-utils gains defineEnv().importEnv for importing from the environment module without branching on mode, plus recognition of the nub package manager ([email protected]/0.3.2, #1150, #1187)
• +error.svelte now gets its page and error props typed automatically, with no extra setup ([email protected]/[email protected], #3076)
• svelte-language-server drops its lodash dependency for a smaller install and faster startup ([email protected], #3038)
• The Svelte Inspector adds a context menu with the current component stack, making it easier to jump between parent and child components ([email protected], #1370)
• The @sveltejs/opencode plugin now ships a TUI variant for terminal workflows ([email protected], #231)
• @sveltejs/opencode also gains an autoupdate option so the plugin can keep itself current ([email protected], #238)

Want to dive deeper? Check out the Svelte CLI and language-tools releases. For all the minor changes and bugfixes that came out in the Svelte compiler this month, you can read the full Svelte CHANGELOG.

That's it for this month! Let us know if we missed anything on Reddit or Discord.

Until next time 👋🏼!

Patch Changes

• chore: drop dead code that make TSGO fail (#18496)
• fix: don't (re)connect deriveds when read inside branch/root effects (#18527)
• fix: skip unnecessary derived effect in earlier batch (#18525)
• fix: avoid declaration tag warning in event handlers (#18500)
• fix: abort deriveds own AbortSignal when it disconnects (#18400)
• fix: ensure $state.eager() is correctly transormed for SSR output (#18530)
• fix: correctly transform declaration tags during SSR (#18492)
• fix: transform computed keys in keyed {#each} destructuring patterns (#18521)
• fix: chain preprocessor sourcemaps with an empty sources[0] instead of dropping them (#18518)
• fix: clear previous_task reference after abort in Tween to prevent memory leak on interrupted tweens (#18541)
• fix: don't treat declaration tags as parts inside each blocks (#18507)

SvelteKit config in vite.config, explicit env vars and new declaration tag support across the toolchain

This month brought a real shift in how SvelteKit projects are configured. You can now define your SvelteKit config directly inside vite.config.js and skip svelte.config.js entirely. We also got the first preview of explicit environment variables, which will eventually replace $env/* modules in SvelteKit 3.

On top of that, the language tools and the sv CLI both caught up with Svelte's new {const ...} declaration tags, so the whole toolchain is now in sync.

Let's dive in!

What's new in SvelteKit permalink

What's new in SvelteKit

• You can now pass your SvelteKit config directly to the Vite plugin, so a separate svelte.config.js is no longer required, as a preview of how Kit 3 will require config to live in vite.config.js (2.62.0, Docs, #15944)
• Experimental explicit environment variables let you declare and type your env vars in one place, as a preview of how $env/* will work in SvelteKit 3 (2.63.0, Docs, #15934)
• Remote function commands can now receive File objects directly, so you can upload files without manually wrapping them in FormData (2.64.0, Docs, #15978)
• Remote queries can now refresh other queries, making it easier to invalidate related data after a mutation (2.65.0, Docs, #16012)
• Prerendered .md and .mdx files are now precompressed alongside HTML, JS and CSS for faster delivery (2.66.0, Docs, #15893)
• SvelteKit now warns when boolean fields in remote form schemas are not marked optional, which is a common cause of silent submit failures (2.66.0, Docs, #15804)
• The new prerender.handleInvalidUrl option lets you customize how invalid URLs found during crawling are reported (2.67.0, Docs, #16088)
• RemoteFormEnhanceInstance and RemoteFormEnhanceCallback are now exported types, so you can type your custom enhance callbacks directly (2.68.0, Docs, #15816)
• Submitted submit fields now keep their value in the form action payload, which makes multi-button forms easier to handle on the server (2.68.0, Docs, #15979)

For all the features and bugfixes that landed this month, check out the SvelteKit / Adapter CHANGELOGs.

What's new in the Svelte CLI and Language Tools permalink

What's new in the Svelte CLI and Language Tools

• The Svelte CLI demo template now uses the new {const ...} declaration tag, so newly created projects show off the latest Svelte syntax ([email protected], #1110)
• sv create now scaffolds projects against @sveltejs/kit ^2.62.0 and moves the Svelte config into the Vite plugin by default ([email protected], #1119)
• A new experimental add-on lets you toggle experimental flags and opt into @next versions directly from the CLI ([email protected], #1121)
• The drizzle and better-auth add-ons now support SvelteKit's new explicit environment variables ([email protected], #1122)
• New defineEnv and svelteConfig helpers in @sveltejs/sv-utils make it easier to read and edit a project's Svelte config from add-ons ([email protected])
• The Svelte language server, svelte-check, and svelte2tsx now understand Svelte 5's {const ...} declaration tags ([email protected]/[email protected]/[email protected], #3033)
• CSS completions now work inside nested

Patch Changes

• fix: error at compile time on duplicate snippet/declaration tag definitions (#18351)
• fix: parse declaration tag contents more robustly (#18353)
• fix: correctly transform references to earlier declarators in a declaration tag (e.g. {let a = $state(0), b = $derived(a * 2)}) (#18348)
• fix: avoid spurious state_referenced_locally warnings for $derived declarations in declaration tags (#18348)
• fix: tolerate whitespace before let/const in declaration tags (#18348)
• fix: prevent infinite loop when a tag's expression ends with a trailing / at the end of the input (#18350)
• fix: more robust parsing of declaration tags with regards to type (#18330)
• fix: preserve newlines in spread input values when the type attribute is applied after value (#18345)
• fix: update SvelteURLSearchParams when setting duplicate keys to the same joined value (#18336)
• fix: check references for blockers on server, too (#18352)

Patch Changes

• fix: unlink errored and otherwise finished batch (#18264)
• perf: walk composedPath() directly in delegated event propagation (#18268)
• fix: transfer effects when merging batches (#18254)
• fix: allow $derived(await ...) in disconnected effect roots (#18273)
• fix: remove temporary raw-text hydration markers (#18269)
• fix: propagate async @const blockers through closure references so template expressions like {(() => host)()} correctly wait for the awaited value (#18309)
• fix: properly unlink batches (#18298)
• fix: settle discarded batch (#18290)
• fix: declare let: directives before {@const} declarations on slotted elements (#18271)
• fix: resume outro-ed branches if they were kept around (#18291)
• fix: avoid waterfall-warning when async resolves to same value (#18297)
• fix: correctly coordinate component-level effects inside async blocks (#18260)
• fix: make unnecessary commit work less likely (#18263)
• chore: add tag name to a11y_click_events_have_key_events warning (#18272)
• fix: catch rejected promises while merging/committing (#18266)