SvelteKit 3 @next previews started in July 2026

The August 2026 Svelte Blog update treats the first @next preview releases of SvelteKit 3 as the main technical story. According to the primary source, thirteen preview versions shipped during July 2026, covering $app/manifest‘,‘$app/service-worker, better API availability and type checking in service workers, tracing, shallow routing through goto, and more.

The important boundary is that SvelteKit 3 is presented as a prerelease, not as a stable production upgrade. This is best read as an early map of the next major version, especially for teams that want to identify affected routing, service worker, observability, or remote function code before the final release.

The official version-3 SvelteKit CHANGELOG records the preview changes from 3.0.0-next.5 onward. It is the better place to inspect breaking changes and smaller fixes behind the blog summary.

koharu tone="note" portrait="characters/deformed/thinking.webp" Preview releases are a good way to explore what is coming. Keep that separate from a production migration decision, and note the code paths that may need attention.

goto gains shallow routing state while pushState and replaceState move toward deprecation

One of the most visible SvelteKit 3 preview changes is the new shallow routing state option on goto. The primary source says 3.0.0-next.13 bakes shallow routing into goto, adds persistState: true for preserving state across reloads, and replaces pushState and replaceState.

This builds on the existing SvelteKit shallow routing model. The current official documentation explains shallow routing as a way to create history entries without navigating and to read state through page.state. The official $app/navigation reference also documents pushState, replaceState, goto state, and refreshAll in the same API area.

The same 3.0.0-next.13 entry also records a breaking change that collapses goto options such as noScroll and keepFocus, and their matching data-sveltekit-* attributes, into a single reset option. Apps that use modals, drawers, browser back behavior, or custom focus and scroll handling should treat this as a UX review point, not only a rename.

$app/manifest‘and‘$app/service-worker make build output and service worker integration more explicit

The primary source introduces a new $app/manifest module in SvelteKit 3 preview. It exposes immutable, assets, prerendered, and routes; the official CHANGELOG confirms the same item as a 3.0.0-next.12 minor change.

That matters when an app needs to inspect build output at runtime. It is especially relevant for service worker strategies that need to reason about prerendered routes, static assets, or immutable output. The primary source does not provide a full migration recipe or a final stable API guarantee, so this should stay in the preview-review bucket.

The same preview release line also replaces the old $service-worker‘modulewith‘$app/service-worker and makes $app/paths importable inside service workers. Teams that customize service workers or handle base paths and asset paths there should read this part of the SvelteKit 3 CHANGELOG early.

refreshAll, tracing, and production sourcemaps point to operational changes

The primary source also highlights refreshAll, tracing leaving the experimental namespace, and production build sourcemap support. The official CHANGELOG records refreshAll and the deprecation of invalidateAll in 3.0.0-next.8, tracing moving out of the experimental namespace in 3.0.0-next.7, and production sourcemaps in 3.0.0-next.11.

The official reference describes refreshAll as an API that refreshes currently active remote functions and reruns load functions unless disabled by option. If an application already calls invalidateAll or coordinates data refreshes across remote functions and load, this is a concrete area to inventory before a future major upgrade.

Tracing and sourcemaps sit closer to operations than day-to-day component work. Because this is still preview material, the article should not overstate production readiness. Still, teams with existing error debugging, tracing, or release artifact workflows have a clear reason to follow the SvelteKit 3 preview notes.

The SvelteKit 2 stable line adds remote form and environment helper updates

The primary source also covers the stable SvelteKit 2 line. It says 2.69.0 adds a submitted property to remote forms so UI can react when a form is submitted, before waiting for the response. The official remote functions documentation describes form as a server-writing helper that works without JavaScript and progressively enhances submission without a full page reload.

In 2.70.0, defineEnvVars moved from @sveltejs/kit to @sveltejs/kit/env. The official @sveltejs/kit/env reference lists defineEnvVars as a utility for defining environment variables exposed through $app/env/public‘and‘$app/env/private.

These two changes can matter even if a project is not trying SvelteKit 3 yet. Remote form users can consider whether submitted simplifies submit-state UI, while projects importing defineEnvVars should check whether the new subpath is reflected in their codebase and dependency version.

svelte-check 4.7.3 adds zero-config props for +error.svelte

For Svelte language-tools, the primary source says [email protected] and [email protected] add automatic typing for the page and error props in +error.svelte. The official svelte-check changelog records zero-config +error.svelte props as a 4.7.3 patch change.

Error pages are often less frequently edited than ordinary routes, so type helper code can linger there. After updating language tools, projects that reference page or error in +error.svelte can check whether existing local type workarounds are still needed.

The primary source also includes Svelte CLI updates around [email protected]. The official Svelte CLI changelog records smarter package manager selection in nested workspaces, addOption availability during setup, and broader formatting from the prettier add-on. These are mainly useful for project creation and add-on authoring workflows.

Treat SvelteKit 3 preview as something to test, not as a migration deadline

The update makes SvelteKit 3 preview look broad: routing, service workers, manifests, remote functions, tracing, and sourcemaps are all involved. The primary source does not state a stable SvelteKit 3 release date or a migration deadline.

A practical next step is to try @next in a small branch or sample app and classify the affected code paths. Code that uses pushState, replaceState, invalidateAll, $service-worker, or the old defineEnvVars import path is worth listing against the SvelteKit 3 and SvelteKit 2 changelogs.

The Svelte monthly update also includes community projects and learning resources, but the technical core for framework users is the SvelteKit 3 preview plus the related stable-line, CLI, and language-tools updates. Reading in that order keeps the signal clear.

Source

• Title: What’s new in Svelte: August 2026
• URL: https://svelte.dev/blog/whats-new-in-svelte-august-2026