Svelte / Advanced: rendering, resources and release evidence / Lesson 18

Svelte 5, Kit 3 migration and release evidence

Review runes, component APIs and current Kit conventions as one versioned contract with reproducible artifacts.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish legacy component compatibility from new runes behavior.
Preserve native/enhanced forms, server policy and rollback across toolchain changes.

Pin exact versions before interpreting migration advice

This course selects Svelte 5 runes concepts and the current Kit 3 documentation reviewed on 2026-10-28. It does not assert a latest patch or permanent support policy. Match Svelte, Kit, Vite, adapter, TypeScript, test runner and runtime requirements for the intended action. A Node release capable of the local models does not certify every compiler or adapter. Legacy Svelte syntax can coexist under supported compatibility rules, but a component’s mode affects which declarations and lifecycle assumptions apply. Do not mix snippets from several majors and treat successful text editing as a completed migration.

Separate pure derivations from legacy side effects

Moving from legacy reactivity to runes requires more than wrapping every let or replacing every $: with an effect. Choose $state for sources, $derived for pure calculations and $effect for browser external synchronization with cleanup. Effect SSR behavior differs from legacy reactive statements, so review initial HTML. Event attributes/callback props, explicit $bindable ownership and snippets also change component contracts. Imperative component creation has documented Svelte 5 APIs rather than assuming every component remains a class constructed with new. Automated migration can assist syntax, but needs human review for domain ownership, async work and current-value semantics.

Retain current Kit conventions with concrete fixtures

The reviewed Kit 3 guide moves configuration into the Vite plugin, replaces generated $lib assumptions with declared #lib imports and introduces declared environment access through $app/env/private/public. Older $env modules are legacy/deprecated, and json/text helpers are deprecated in favor of Web Response APIs. Review enhanced forms that target another page and the actual status returned for fail rather than copying an older callback expectation. Current origin protection/trusted-origin configuration also differs from a legacy disable switch. The JSON checklist records these review requirements; no package upgrade, codemod or framework execution occurs here.

json Synthetic versioned migration checklist

{"selectedMajors":{"svelte":5,"sveltekit":3},"checks":["runes-vs-legacy-mode","effect-ssr-and-cleanup","callback-and-binding-contracts","vite-plugin-config","declared-#lib-imports","declared-env-visibility","enhanced-form-navigation-status","web-response-helpers","origin-policy"],"execution":"review-only"}

The checklist describes required evidence. It is not a completed upgrade or a record of passing build tests.

Check a declared release record without pretending it is evidence

The local predicate requires the selected majors, an explicit component mode and a reviewed artifact marker. It validates completeness of this synthetic record only. A real pipeline must attach immutable lockfile, configuration, environment schema and compiled output identities to authentic tool results. Rollback can fail when a newer client, retained form contract or source schema is incompatible with an older server. Preserve intended old/new combinations instead of assuming a package-number reversal recreates the earlier system. A Boolean named reviewed is a requirement marker, not proof that someone ran a build or browser fixture.

javascript Complete offline release-record check

function releaseRecord(v){return v.svelte===5 && v.kit===3 && ["runes","legacy-reviewed"].includes(v.mode) && v.artifactsReviewed===true;}
console.assert(releaseRecord({svelte:5,kit:3,mode:"runes",artifactsReviewed:true}));
console.assert(!releaseRecord({svelte:5,kit:3,mode:"runes"}));

The complete record passes and missing review fails. No version compatibility or tool execution is certified.

Publish claims that match executed boundaries

A complete integration review covers compiler behavior, props/ownership, keyed state, effects, SSR/hydration, load/action hooks, current authorization, source results and adapter/environment behavior. Keep direct helper checks distinct from component, browser and server evidence. This course executes local JavaScript and parses JSON only, with all framework blocks marked runnable:false. It does not install dependencies, compile Svelte, start Kit, inspect real credentials, access a database or deploy infrastructure. Before independent practice, choose supported patches and reproduce the relevant boundaries in an authorized isolated project. Stop at the scope actually authorized rather than expanding a migration into unrelated operational changes.

Common errors and fixes

Every legacy reactive statement becomes an effect

Why it happens: Pure calculation and browser side-effect timing were treated as equivalent.
How to fix it: Separate sources, derivations and external synchronization deliberately.
Prevent it next time: Verify SSR output and cleanup after the migration.

A Kit 2 configuration is assumed valid unchanged in Kit 3

Why it happens: Versioned config, alias and env conventions were not reviewed.
How to fix it: Use the current official migration contract and exact adapter/tool versions.
Prevent it next time: Retain native/enhanced form and import-resolution fixtures.

A review Boolean is called a passing build

Why it happens: Declared record completeness was confused with executed tool evidence.
How to fix it: Attach actual artifact identities and results to release claims.
Prevent it next time: State unexecuted compiler/browser/server boundaries explicitly.

Check your understanding

1. Does the releaseRecord test prove that Kit 3 compiles the application?

Show worked solution

No. It checks fields in an ordinary object. It does not load packages, resolve #lib, validate an env declaration or compile a component. Keep it as a completeness guard and attach real authorized tool results before claiming migration success.

2. Why preserve both native and enhanced form fixtures during migration?