BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News SvelteKit 3 Reaches Release Candidate, Moving Config to Vite and Retiring the $lib Alias

SvelteKit 3 Reaches Release Candidate, Moving Config to Vite and Retiring the $lib Alias

Listen to this article -  0:00

The Svelte team has moved SvelteKit 3 into the release candidate phase, framing the update as a chance to prune older code and lay groundwork for the framework's evolution rather than as a feature heavy launch. A stable release with no further breaking changes is expected to follow if testing goes smoothly.

The headline shift is where configuration lives as SvelteKit 2's svelte.config.js is gone, and configuration now sits in vite.config.ts so the Vite plugin can read it synchronously instead of waiting on an asynchronous resolution step that could not start until the full Vite config resolved. The reference docs note that configuring through Vite arrived back in version 2.62, so the RC finalises a transition already underway.

The most debated change is the retirement of the $lib alias in favour of #lib, which leans on Node's native subpath imports declared in package.json rather than a SvelteKit specific path that Vite and TypeScript had to coordinate. Developers also now need file extensions, turning $lib/foo into #lib/foo.js.

The migration guide points existing apps at the CLI command:

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

On Reddit, one developer wrote that they hate the lib change:

I hate the $lib->#lib change, it now makes it inconsistent with other things like $app. Hopefully it's not enforced to be #lib and we can just use whatever alias we want

While a replier agreed before conceding it was "a great change":

Yeah what's the logic in that?

Edit: oh nvm it's a great change. They're moving it to the native package.json alias definition. This means you can use the alias in lib/server stuff that you might want to run without sveltekit too.

In the original GitHub issue, maintainer Rich Harris was candid about the tradeoff, saying he would "love for everyone to use nodenext" but that "users might revolt" over extensionless imports, adding that anyone opposed "can always create their own alias".

tsconfig.json now extends $app/tsconfig instead of the generated .svelte-kit file, service workers pull from $app/env, $app/paths and a new $app/manifest module, and explicit environment variables graduate from experimental with optional Standard Schema validation. Error handling also improves now that SvelteKit 3 requires Svelte 5: +error.svelte components render on both load and render failures, every error flows through handleError, and stack traces get sourcemaps. Shallow routing moves from pushState to goto with a shallow: true option.

Under the hood, SvelteKit 3 now requires Vite 8 and its Rolldown bundler for faster builds, though the team declined to adopt FetchableDevEnvironment, arguing it forces frameworks to absorb too much complexity. Still behind an experimental flag are remote functions, a type safe client server RPC approach that echoes React Server Actions and Next.js server functions, and which the team says makes load functions and actions "look a bit clunky" by comparison.

SvelteKit is the official application framework for Svelte, built on top of Vite and maintained by the Svelte team, now part of Vercel. It handles routing, server-side rendering, data loading and deployment adapters so developers can build full-stack web applications with the compiler-based Svelte UI framework rather than a virtual DOM. Since its 1.0 release in late 2022 it has become the default way to build Svelte apps, positioning itself against React frameworks like Next.js and Remix while leaning on Svelte's smaller runtime and reactive syntax.

About the Author

Rate this Article

Adoption
Style

BT