SvelteKit 3 reaches release candidate: configuration moves into Vite and remote functions arrive

SvelteKit 3 has entered its release-candidate phase. The team promises a stable release “in the near future, with no further breaking changes”, which makes this RC the base projects can start planning their upgrade against. It is more than a spring clean: configuration changes files, remote functions reshape client-server communication, and a migration command takes on most of the mechanical work.

#Configuration moves into Vite

The most visible change is how a project is configured. Configuration leaves svelte.config.js for vite.config.ts: SvelteKit 3 now leans fully on Vite 8, which it requires, and on Svelte 5. Along the way, the long-standing $lib alias gives way to #lib subpath imports, and the TypeScript setup is simplified by extending $app/tsconfig instead of a verbose generated file.

The shift aligns SvelteKit with the tooling most modern JavaScript projects already use. It has a cost: existing configuration files must be rewritten, and integrations that read svelte.config.js will need to adapt.

#Remote functions, the heart of the release

The feature that shapes this version has a name: remote functions. They let you call server code directly from a component with end-to-end type inference — no +server.ts file, no hand-wired fetch calls, and no manually keeping request and response types in sync. Four primitives cover the common cases: query to read data, form for form submissions, command for mutations, and prerender for values computed at build time.

// data.remote.ts
import { query } from '$app/server';

export const listArticles = query(async () => {
  // exécuté sur le serveur, typé jusque dans le composant
  return await db.articles.findMany();
});

In the component, the function is imported and awaited like any async function, turning the network boundary into an implementation detail rather than a contract to maintain.

By removing the +server.ts file from a simple data read, SvelteKit 3 brings server code closer to the component that consumes it.

#Shallow routing, errors and tracing

Several lower-level APIs are reworked. Shallow routing is now built into goto(), with no separate module. The signature of error() changes: the message becomes a first-class argument. invalidateAll() is renamed refreshAll(), the old name staying deprecated through the transition.

Two new modules appear. $app/manifest exposes information about assets, prerendered pages and routes at runtime; $app/service-worker, together with $app/paths now available in that context, improves service-worker authoring. Tracing moves out of the experimental namespace, and production sourcemaps are supported, including for tying a stack trace back to its source.

#Migration: one tool, a few breaks

SvelteKit ships a migration command that handles most of the work and lists what remains to be done by hand. A fresh project scaffolds with the same tooling in its “next” version.

# migrer un projet existant
npx sv@next migrate sveltekit-3 --tasks all --confirm

# démarrer un nouveau projet
npx sv@next create my-new-app

The table below sums up the structural moves to anticipate.

#What to take away

SvelteKit 3 is not a cosmetic revision: moving configuration into Vite and renaming several APIs force a migration, one the dedicated tool thankfully makes fairly painless. The real promise lies in remote functions, which aim to make the manual API layer between server and component disappear — but they remain experimental, and they are what to keep an eye on before the stable release.

Further reading: the official release-candidate announcement, “The SvelteKit 3 Release Candidate is here” on the Svelte blog.