Svelte 6 replaces stores with signals across the entire framework

Svelte 6 reached release candidate on Sunday and removes the store contract that has been the framework's state primitive since 2019. Runes, the signal-based system introduced in Svelte 5, become the only mechanism. Writable and readable stores continue to work through a compatibility shim that will be removed in Svelte 7, and the dollar-prefix auto-subscription syntax produces a deprecation warning. The core team's argument is that maintaining two reactivity systems has cost them significant complexity and produced a framework where the correct approach depends on context in ways new users find confusing. They are right about that and the transition will still be painful for library authors.

What changes for application code

For a component using local reactive state, nothing changes, since that has been runes since version 5. The affected code is shared state: a store exported from a module and imported by several components. That pattern becomes a rune-based state object exported from a file with a dot-ts or dot-svelte-dot-ts extension, and consumers access properties directly rather than through a subscription.

export async function handler(request: Request): Promise<Response> {  const started = Date.now();  const upstream = await fetch(request);  const headers = new Headers(upstream.headers);  headers.set("x-skarvonix-ms", String(Date.now() - started));  return new Response(upstream.body, {    status: upstream.status,    headers,  });}

The migration is mechanical enough that the Svelte team shipped a codemod handling roughly 85 percent of cases automatically. The remaining 15 percent are stores with custom subscribe implementations, derived stores with complex dependency graphs, and anywhere the store object itself is passed around rather than its value. Those need human attention and the compiler now produces reasonably specific errors pointing at them.

Why the team did it

Two reactivity systems meant two mental models, two sets of documentation, and two paths through the compiler. Rich Harris wrote in the release announcement that the store contract's design, a subscribe function returning an unsubscribe function, forced allocation and indirection that signals avoid, and that supporting both prevented several optimizations. Benchmarks in the release show a 15 to 30 percent reduction in update overhead for applications that had been using stores heavily.

There is also a coherence argument that matters more than performance. A new developer learning Svelte encountered runes for component state and stores for shared state, with rules about when each applied that nobody could summarize in a sentence. Unifying on one primitive makes the framework teachable again, and teachability has been Svelte's main advantage over React since the beginning.

The ecosystem problem

Every Svelte library that exposes state does so through stores, because that was the contract. Those libraries work under the compatibility shim and will break in Svelte 7. The Svelte team estimates about 2,400 packages on npm are affected. The large ones will update. The long tail will not, and applications depending on an unmaintained store-based library will be stuck.

SvelteKit, which the same team maintains, ships its own migration in a coordinated release. The page and navigating stores become rune-based state objects. That is a breaking change to the most commonly used API in the ecosystem and it is unavoidable given the direction. The team has published a compatibility timeline promising the shim through at least mid-2028, which gives library authors roughly two years.

How Svelte compares now

Signals have become the consensus reactivity model across frontend frameworks. Solid pioneered the current generation, Vue adopted them internally years ago, Angular shipped them in version 16, Preact added them, and there is a TC39 proposal to standardize a signal primitive in JavaScript itself. React remains the outlier, having chosen a compiler that optimizes its existing model rather than adopting signals, a decision the React team has defended at length.

Svelte's position among the signal frameworks is that its compiler does more work, producing smaller bundles and less runtime. A hello-world Svelte 6 application ships about 2.1 kilobytes of runtime against Solid's 7 and Vue's 34. Whether that matters depends entirely on your application, and for a large application the runtime difference is noise against your own code.

Should you upgrade

New projects should start on Svelte 6 when it goes stable, expected in September. Existing projects should upgrade when convenient and there is no urgency, since Svelte 5 will receive security fixes into 2028. The codemod makes the mechanical work fast, and the risk is concentrated in third-party dependencies rather than in your own code.

The one group that should wait is anyone with a heavy dependency on libraries that have not announced Svelte 6 support. Check your dependency list against the community-maintained compatibility tracker before starting. Upgrading and then discovering that your form library or your chart component does not work is a bad Tuesday, and the tracker exists precisely because enough people had that experience during the Svelte 5 transition.

It is also worth being honest that two breaking reactivity migrations in three releases has cost Svelte some goodwill. The framework's appeal was always that it asked less of you than React did, and a team that rewrote its state layer for runes in 2024 and is now rewriting its shared state for Svelte 6 has spent budget on churn rather than product. The core team's position is that the destination is stable and the path there required two steps. That is probably true and it is not the argument you want to be making to a technical director choosing a framework for a five year project.

Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.