Loading today’s stories
Build1 distinct publisher3 min readPublished
SvelteKit 3 is at Release Candidate, but every entry in the same report is still tagged 3.0.0-next and three of them are breaking, so the thing to plan for is the CLI task that bumps dependencies and changes your import prefix in one pass.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Read the sv-utils entry before you read the RC announcement. `@sveltejs/sv-utils` gained `isKit3`, `resolveLibPrefix` and `libSubpathImports` so that add-ons can handle SvelteKit 2 and 3 transparently [16]. Those are helpers for asking, at code-generation time, which import prefix the project in front of you actually uses. You only need that helper if the prefix reaches code you did not write.
`#lib` is a Node subpath import, and projects the CLI creates now use it in place of `$lib` [5]. The prefix appears in every module that imports from your own library directory. If four hundred files import from `$lib`, the rewrite touches four hundred files, and the task does that part [4]. The part it cannot do arrives as a list: `sv migrate` now writes out the changes a developer or an agent should resolve when automatic migration is not possible [4]. That list is the honest half of the tool, and it is where the hours are.
The tooling expects to meet you mid-flight. svelte-check 4.7.6, svelte2tsx 0.7.61 and svelte-language-server 0.18.4 all learned SvelteKit 3's flattened config structure specifically so type generation and diagnostics keep working through the migration [17]. A half-migrated repository is a supported state.
Then the label. Every SvelteKit 3 entry in the report is tagged `3.0.0-next`, running from next.17 to next.25, which is nine numbered prereleases inside one month [2]. Three of the eight listed changes carry a breaking marker [1]: cross-page form actions now navigate to the action page on success and on failure [6], adapter Vite plugins split into `pre` and `post` groups [7], and `defineParams` moved to `@sveltejs/kit/params` [8]. A release candidate that is still relocating exports is a candidate for the next candidate. The additions you can ignore until you land are the pleasant ones: a `QUERY` handler export in `+server.js` [10], an `applyReroute` helper for adapters doing split serverless deployments [11], and `+` files with `test`, `spec` or `stories` in their names no longer becoming routes [9].
For the `sveltekit-3` task to be a quiet afternoon in your repo rather than a week, some things have to hold. Your `$lib` imports need to be literal strings rather than assembled paths. Nothing can depend on `defineParams` living where it used to live [8]. Your form actions have to tolerate ending up on the action page when they fail [6]. Your docs and internal templates need doing by hand, because the version 3 documentation currently lives on next.svelte.dev and the full changelog sits on a version-3 branch [14]. In my context that argues for running the task on a throwaway branch this month, reading the leftover list, and merging when the tag says rc.
Ranked by verification strength, evidence, and original report placement.
Svelte 5.57 shipped with new SvelteMap methods and a few quality-of-life additions, while SvelteKit 3 got closer to the finish line with its Release Candidate.
sv@next now ships a task-based sveltekit-3 migration for existing apps.
sv migrate has been reworked to prepare for the SvelteKit 3 migration: it lists tasks, ships a sveltekit-3 task that bumps dependencies and rewrites $lib to #lib, adds an $app/state task, delegates older migrations to svelte-migrate@1, and creates a list of changes a developer or agent should resolve if they cannot be migrated automatically ([email protected]).
The sv CLI's mcp add-on has been replaced with a broader ai-tools add-on that can set up the Svelte plugin (Claude Code, opencode) or pick individual tools (MCP server, skills, sub-agents) per client ([email protected]).
Newly created projects use #lib (Node subpath imports) instead of $lib, matching SvelteKit 3 ([email protected]).
Enhanced cross-page form actions now navigate to the action page on success and failure, matching native form behavior (3.0.0-next.17, marked breaking).
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 31, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Six specifications decide whether an agent can move off the harness it was built on1 distinct publisher
build
Cloudflare pins shadow MCP traffic on three protocol headers1 distinct publisher
product
LangChain's dcode and NVIDIA's NemoClaw sell controls, not code quality1 distinct publisher
build
Zalando's durable agentic engineering win was a proxy, not a model1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Checkable to the version number, single-handed
Almost everything here is pinned: 5.57.0, nine prerelease tags, three 2.x patches, [email protected], and issue numbers next to each bullet a reader can open. That is unusually falsifiable for a release post. The exception is the one claim the story leans on hardest — that SvelteKit 3 has reached Release Candidate — which is asserted in prose with no tag, date or criteria attached, and no second account to check it against.
Plenty shipped, nobody counted
Shipping is well documented and use is not documented at all. We can see a feature release, a nine-deep prerelease run, three maintenance patches and a coordinated tooling update land inside one month — but not a single figure for how many projects have run the sveltekit-3 task, and the task itself only exists on a next-tagged CLI. Production Svelte, on the evidence here, is still the 2.70.x line.
RC in the intro, next.25 in the list
The mismatch is small and it is right there on the page. A Release Candidate implies feature freeze; the bullets underneath move defineParams to a new module, reorder the adapter plugin pipeline and change where form actions navigate on failure, all marked breaking. Nothing is invented — the tags are printed honestly — but a reader who stops at the first paragraph will think the migration is more settled than the list admits.
The project reporting on the project
Svelte publishes this round-up about Svelte, and its interest is in a major version that looks calm to migrate to — hence the emphasis on a CLI task that does the rewrite for you and tooling that spans both versions. There is nothing to sell and no paywall, and the breaking markers are left in plain sight, which limits how far the framing can drift. Still, the softest sentence in the piece is the one that flatters the release, and the hardest questions about the migration are the ones not asked.
Firm on the mechanics, thin on the milestone
Take the mechanical claims as reliable: version numbers, the $lib to #lib rewrite, the three breaking items, the language-tools updates. Discount the Release Candidate label until a stable tag or a second source backs it, and treat everything about impact — how much manual cleanup the migration leaves, which adapters survive the plugin split — as unmeasured rather than reassuring.