SvelteKit 3の@nextプレビューが2026年7月に始動

Svelte Blogの2026年8月更新では、SvelteKit 3の最初の@nextプレビュー群が中心に扱われています。`goto`によるshallow routing、`$app/manifest`、`$app/service-worker`、`refreshAll`など、正式移行前に見ておきたい変更がまとまっています。

こはるの読みどころ

SvelteKit 3はまだプレビューなので、今すぐ本番更新を急ぐ話ではありません。既存アプリのルーティング、service worker、remote functions、環境変数まわりに触れている人ほど、どこが次期メジャーで変わるのかを早めに棚卸ししやすい内容です。

SvelteKit 3の@nextプレビューが2026年7月に始動

Svelte Blogの2026年8月更新は、2026年7月に出たSvelteKit 3の最初の@nextプレビュー群を大きなトピックとして扱っています。一次ソースによると、7月中に13本のプレビュー版が出ており、 $a p p / m a n i f e s t ‘ 、 ‘$ app/service-worker、service worker内のAPI利用と型チェック、tracing、gotoに組み込まれるshallow routingなどが取り上げられています。

ここで大事なのは、SvelteKit 3が正式安定版として案内されているわけではなく、一次ソースもprereleaseとして試す価値がある、という位置づけで書いている点です。実運用へ即時移行する話というより、次のメジャーでどの設計面が動きそうかを読む更新ですね。

SvelteKit側のversion-3ブランチのCHANGELOGでも、3.0.0-next.5以降のプレビュー変更がまとまっています。一次ソースの短い要約だけでなく、破壊的変更や細かな修正を追う場合は、このCHANGELOGを合わせて見るのがよさそうです。

koharu tone="note" portrait="characters/deformed/thinking.webp" プレビュー版は、便利そうな変更を先に触れるための入口だね。正式版の移行判断とは分けて、いまのコードで影響しそうな場所をメモしておくと読みやすいよ。

`goto`にshallow routingの`state`が入り、`pushState`と`replaceState`は非推奨へ向かう

SvelteKit 3 previewの目立つ変更のひとつは、gotoにshallow routing用のstateオプションが入ることです。一次ソースは、3.0.0-next.13でgotoにshallow routingが組み込まれ、persistState: trueでリロードをまたいで状態を保持できるようになり、pushStateとreplaceStateを置き換える、と説明しています。

この流れは、既存のSvelteKitのshallow routingの考え方とつながっています。現行の公式ドキュメントでは、shallow routingはページ遷移なしで履歴エントリを作り、page.stateに状態を持たせる仕組みとして説明されています。$app/navigationの公式リファレンスにも、pushState、replaceState、gotoのstate、refreshAllが並んでいます。

同じ3.0.0-next.13では、gotoのnoScrollとkeepFocus、および対応するdata-sveltekit-*属性を単一のresetオプションへ寄せる破壊的変更も記録されています。モーダル、ドロワー、戻る操作と状態管理を組み合わせているアプリでは、単なるAPI名の変更ではなく、ナビゲーション時のUX確認まで含めて見ておきたいところです。

`$a p p / m a n i f e s t ‘ と ‘$ app/service-worker`でビルド出力とSW連携が見えやすくなる

一次ソースは、SvelteKit 3 previewで新しい$app/manifestモジュールが追加され、immutable、assets、prerendered、routesを公開すると紹介しています。公式CHANGELOGでも、3.0.0-next.12のminor changeとして同じ項目が確認できます。

これは、アプリのビルド結果を実行時に参照したい場面に関係します。特にプリレンダー済みルート、静的アセット、immutableな成果物をサービスワーカーや配信戦略と合わせて扱う場合、今後の設計余地が広がる変更と読めます。ただし、一次ソースは具体的な移行手順や安定版での最終API保証までは示していません。

同じ3.0.0-next.12では、従来の $s e r v i c e - w o r k e r ‘ が削除され、新しい ‘$ app/service-workerモジュールに置き換わる流れも示されています。さらに$app/pathsがservice worker内でimport可能になるため、ベースパスやアセットパスをservice worker側で扱う構成では、次期メジャーの変更点として早めに読んでおきたいですね。

`refreshAll`、tracing、production sourcemapは運用寄りの変更として効いてくる

一次ソースは、refreshAllがinvalidateAllを置き換え、tracingがexperimental namespaceから外れ、production buildでsourcemapがサポートされることもSvelteKit 3 previewのハイライトとして挙げています。公式CHANGELOGでは、3.0.0-next.8でrefreshAll追加とinvalidateAll非推奨、3.0.0-next.7でtracingのexperimental namespace離脱、3.0.0-next.11でproduction sourcemap対応が確認できます。

refreshAllは、公式リファレンス上では現在有効なremote functionsとload関数の再実行に関わるAPIとして説明されています。remote functionsやloadの再取得を明示的に呼ぶコードがある場合、invalidateAll前提の設計を棚卸しするきっかけになります。

tracingとsourcemapは、日常のコンポーネント実装よりも観測性や障害調査に寄った変更です。まだpreviewなので断定は避けたいですが、SvelteKitを本番運用していてエラー調査、分散トレース、ビルド成果物の追跡を整えているチームほど、SvelteKit 3の変更をCHANGELOGで追う価値があります。

SvelteKit 2のstable lineではremote formsと環境変数ヘルパーが更新

今回の一次ソースはpreviewだけでなく、SvelteKit 2系のstable lineにも触れています。2.69.0ではremote formsにsubmittedプロパティが追加され、レスポンスを待つ前にフォーム送信の瞬間へ反応できるようになった、と説明されています。remote functionsのform自体は、公式ドキュメントでフォームをJavaScriptなしでも動かし、JavaScript利用時にはページ全体を再読み込みせずに送信できる仕組みとして説明されています。

2.70.0では、defineEnvVarsが@sveltejs/kitから@sveltejs/kit/envへ移動しています。公式の@sveltejs/kit/envリファレンスでは、defineEnvVarsが環境変数を定義し、 $a p p / e n v / p u b l i c ‘ と ‘$ app/env/private経由で利用できるユーティリティとして掲載されています。

既存の2系アプリでは、SvelteKit 3 previewを試さなくても、この2つは実装に影響し得ます。remote formsを使っているなら送信直後のUI制御にsubmittedを使えるか、環境変数ヘルパーをimportしているなら新しいsubpathへ寄せるかを、依存バージョンと合わせて見ておくとよさそうです。

svelte-check 4.7.3で`+error.svelte`のprops型付けがゼロ設定に

Svelte language-tools側では、一次ソースが[email protected]と[email protected]で+error.svelteのpageとerror propsが追加設定なしで型付けされるようになった、と紹介しています。公式のsvelte-check changelogにも、4.7.3のpatch changeとしてzero-config +error.svelte propsが記録されています。

エラーページは普段の開発では触る頻度が低くても、型が曖昧なまま残りやすい場所です。+error.svelteでpageやerrorを参照しているプロジェクトでは、language-tools更新後に余分な手元設定が不要になるか、逆に既存の型補助が重複しないかを軽く見ておくと分かりやすいですね。

一次ソースにはSvelte CLIの[email protected]周辺の更新も含まれています。公式のSvelte CLI changelogでは、ネストしたworkspaceのlockfileを考慮したpackage manager選択、setup phaseでのaddOption、prettier add-onの生成ファイル整形などが確認できます。新規プロジェクト作成やadd-on運用のほうに効く更新です。

SvelteKit 3 previewは試す対象であり、移行計画はCHANGELOGで分けて読む

今回の更新を読むと、SvelteKit 3 previewは「大きく変わるAPIを早めに試す」ための段階だと分かります。goto、service worker、manifest、remote functions、tracing、sourcemapと、変更の範囲は広いですが、一次ソースは正式版のリリース日や移行期限を示していません。

実務では、まず検証用ブランチや小さなサンプルで@nextを試し、既存アプリの影響箇所を分類するのが現実的です。特にpushState/replaceState、invalidateAll、$service-worker、defineEnvVarsのimport元に依存しているコードは、SvelteKit 3のCHANGELOGと照らし合わせてリストアップしておくと、後の移行が楽になります。

Svelteの月次更新はコミュニティ紹介も多く含みますが、今回の技術的な読みどころはSvelteKit 3 previewと周辺ツールの型・CLI改善にあります。追いかける順番を決めるなら、まずSvelteKit 3 preview、次にSvelteKit 2 stable line、最後にCLIと言語ツールの更新、という読み方が落ち着いています。