Pimp My IDE / garage dispatch
Back to garage
October 1, 2026 | SvelteKit 3 / migration review / behavior replay

Let the codemod turn the wrench. Keep a hand on the torque.

SvelteKit 3 ships with a migration command that changes what it can and leaves a TODO list for the rest. That is a useful division of labor. It is not a release verdict.

Run the migration on a clean baseline. Review every generated change and TODO. Then replay the routes, errors, environment access, service worker, and deployment behavior that the version bump can move.

The migration command is a patch generator.

SvelteKit 3 is now stable. The release post points existing projects to npx sv migrate sveltekit-3 --tasks all --confirm. The command migrates what it can and generates a TODO list for work it cannot finish automatically.[1]

That contract is better than pretending a codemod can understand every application. It gives automation the mechanical edits and leaves ambiguous work visible. Keep the generated TODO list in the review packet. Do not treat an empty terminal exit as proof that the application survived.

A codemod can move syntax. It cannot certify the behavior that syntax used to produce.

Raise the floor before changing the room.

The migration guide recommends moving to the latest SvelteKit 2 release first so targeted deprecation warnings can expose old usage before the major upgrade. SvelteKit 3 also raises minimum versions for Node, TypeScript, Svelte, and Vite. The documented floors are Node 22.17, TypeScript 6, Svelte 5.57.1, and Vite 8.0.12.[2]

Record those versions in the baseline commit. Run the current build and tests before the migration. If the baseline is already red, the new patch cannot tell you which failure belongs to the upgrade.

Configuration and imports move through real boundaries.

SvelteKit configuration now belongs in the sveltekit Vite plugin instead of svelte.config.js. The $lib alias becomes the standard #lib subpath import. Environment variables and service worker imports also change. Error handling now routes more errors through handleError.[1][2]

These are not one kind of change. Configuration affects builds and adapters. Import changes affect resolution. Environment changes affect public and private data. Service workers affect offline and update behavior. Error changes affect logging and user-visible failure paths. Review and replay each boundary separately.

Use task selection to make smaller patches.

The CLI supports task-based migrations. It can limit files with --files, select work with --tasks, choose a package manager with --install, or skip installation with --no-install. The default Git check can be bypassed with --no-git-check.[3]

Keep the Git check unless an isolated throwaway worktree provides the same protection. On a large application, run bounded task groups and review each patch before starting the next. Smaller patches preserve the reason for each change and make rollback cheaper.

Remote functions are not part of the stable promise yet.

The stable release says remote functions still depend on Async Svelte and an experimental flag. Do not bundle their adoption into a routine SvelteKit 3 migration. Upgrade the framework first. Evaluate the experimental feature as a separate change with its own rollback and evidence.[1]

Interactive makeover / migration pit board

Move the jack. Build the handoff.

Traditional purpose replaced: a migration checklist and one optimistic progress bar. Better version: one native phase shifter controls the active instruction, four independent evidence lamps keep preparation visible, and the copyable card preserves every missing proof field.

Set the migration phase

This teaching rig drafts a review card. It does not inspect a repository, run the migration, or prove an upgrade.

Phase shifter0 / Baseline
Evidence fields to request
Review lift

Current bay instruction

0 of 4 fields selected
Phase 0 / baseline

Prove the old version first.

Update to the newest 2.x release. Record versions and run the checks that define a healthy baseline before changing dependencies.

BasePatchTODOReplay

Review card is empty.

Select the evidence fields that the handoff must request. Real values and command output remain required.

Four checks after the codemod

Test the boundaries that moved.

01 / CONFIG

Can every tool load it?

Exercise the Vite config under development, build, tests, and the chosen adapter.

02 / DATA

Did secrets stay server-side?

Inspect each environment declaration and verify client output does not contain private values.

03 / FAILURE

Do errors take the intended route?

Trigger expected and unexpected errors. Check the page, log, status, and handleError result.

04 / DELIVERY

Does the deployed app behave?

Replay routes, service worker updates, adapter output, and rollback on the target platform.

Sources read

Source log and evidence boundary
  1. The Svelte team, "SvelteKit 3 is here", published and read October 1, 2026. This first-party release post supplies the stable status, migration command, generated TODO behavior, main changes, and the experimental boundary around remote functions.
  2. SvelteKit documentation, "Migrating to SvelteKit v3", read October 1, 2026. This is the detailed source for the recommended 2.x staging step, minimum dependency versions, configuration move, removed and renamed APIs, error behavior, service worker changes, adapters, and response behavior.
  3. Svelte CLI documentation, "sv migrate", read October 1, 2026. This documents task-based migration controls, file globs, task selection, install options, confirmation, working directory, and the Git safety check.

Evidence boundary. Pimp My IDE read the release and migration documentation. This dispatch did not migrate a SvelteKit repository or test SvelteKit 3. The pit board is a planning tool. Its checkboxes select requested evidence fields. They do not record builds, tests, routes, deployment, or rollback results.