The Svelte team published this week's August edition of "What's New in Svelte" — and it reads less like a changelog and more like a SvelteKit 3 roadmap. The preview builds are live, and three API changes stand out as things worth knowing right now.
Shallow routing moves into goto
Until now, shallow routing — updating the URL without triggering a full navigation — required importing `pushState` or `replaceState` directly. In SvelteKit 3 that detour disappears: it moves into `goto` via a new `state` option. Add `persistState: true` if you need the state to survive a page reload. At the same time, `goto`'s `noScroll` and `keepFocus` options merge into a single `reset` option. Fewer knobs, same control — exactly the kind of tidy-up that pays off every time you would otherwise reach for the docs.
Two APIs heading for retirement
`invalidateAll` — the standard way to reload all page data — is deprecated in favour of `refreshAll`. Same behaviour, a name that actually describes it. And `error()` loses its optional-message signature: in SvelteKit 3, calling `error()` without a message is a type error. The reasoning is straightforward — an error with no message is harder to debug, and requiring one costs nothing.
New $app modules and deployment detection
Two new modules land. `$app/manifest` gives read-only access to your build's `immutable`, `assets`, `prerendered` and `routes` fields at runtime — useful for caching strategies and dynamic routing logic without a bespoke build script. `$app/service-worker` replaces the old `$service-worker` import; both it and `$app/paths` are now valid inside service worker context. SvelteKit 3 also ships built-in deployment detection: on data responses, form actions, tab focus and visibility change, the runtime checks whether a new deploy has landed and can react accordingly.
Our take
SvelteKit 3 is getting increasingly concrete. The API changes in this preview follow a consistent pattern — fewer special cases, more predictable defaults, better error feedback. If you are on SvelteKit today, the migration surface is already visible: rename `invalidateAll` to `refreshAll`, make your `error()` messages explicit, and look at `$app/manifest` for anything you currently handle with a separate build script. No stable release date yet, but the direction has been clear for a while.
