wrangler devとViteは何が違うのか——ローカル開発の実態

SvelteKit＋Cloudflareでの開発には、ローカル起動の方法が2通りあります。bunx wrangler devと、Viteの開発サーバーです。package.jsonに"dev": "vite dev"と定義してbun devと打つ運用も多く見られますが、これは単なるコマンドのショートカットで、中身はVite（vite dev）そのものです。本記事でも素直に「Vite」と呼びます。どちらもD1やKVを触れて一見同じように見えますが、起動モデルもDXもかなり違います。まずはその違いを起点に、実務での使い分けを見ていきます。

起動モデルの違い

wrangler dev は、実際のworkerdランタイム（Cloudflare Workersの本物のサンドボックスプロセス）をローカルで起動します。Workerのコードは事前にビルドされ、そのビルド成果物がworkerd上で実行される、本番に最も近い動かし方です。

Vite（@sveltejs/adapter-cloudflareのViteプラグインが内部で使うgetPlatformProxy()）は、Viteの開発サーバー上でSvelteKitのコードをそのまま実行し、D1・KV・R2といったバインディングだけをplatform.env経由で差し込みます。workerdは一切立ち上がりません。

// @sveltejs/adapter-cloudflareの内部でおおよそこう動いている
import { getPlatformProxy } from 'wrangler';

const { env } = await getPlatformProxy();
// env.DB / env.SESSION_KV / env.ASSETS_BUCKET などが
// Viteの開発サーバーのplatform.envとして差し込まれる

DXの違い：ホットリロード vs ビルド必須

実務で体感差が一番大きいのはここです。

Viteはホットモジュールリプレースメント（HMR）に対応しています。 Svelteコンポーネントを編集すると、ブラウザをリロードせずに変更箇所だけが差し替わり、フォームの入力値やページの状態を保ったまま開発を続けられます。保存した瞬間に反映されるフィードバックループの速さが、Viteを使う一番の理由です。

wrangler devはビルドが前提です。 ファイルを変更するたびに、Workerのコード全体を再ビルドしてからworkerdに再デプロイするというサイクルが走ります。HMRのような部分差し替えの仕組みはなく、ブラウザ側もフルリロードになるため、コンポーネントの状態は毎回失われます。ビルドを挟む分だけ、変更の反映にも数秒単位のラグが乗ります。

つまり「コードを1行直して、ブラウザで即確認する」という開発の主なループにおいては、Viteのほうが体験としてはっきり優れています。wrangler devはその代わりに、ビルド成果物が実際にworkerd上で動くかどうか——本番デプロイに近い形での動作確認ができるという強みを持っています。

ストレージ系バインディングはどちらでも同じように動く

D1・KV・R2に関しては、wrangler devとVite（getPlatformProxy()）のどちらで起動しても挙動に差はありません。getPlatformProxy()自体がwranglerパッケージの提供するAPIで、中身は単なるファイルベースのストレージエミュレーションだからです（D1はSQLite、KV・R2もローカルディレクトリ）。

保存先は.wrangler/state/v3/配下で、この永続化パスはwrangler devとVite開発サーバーで共通です。D1であれば実体は.wrangler/state/v3/d1/<database-id>.sqliteという実際のSQLiteファイルで、bunx wrangler d1 execute --localで直接クエリを投げているものと同一です。だからこそ、どちらのコマンドで起動してもD1のデータが同じに見える、という状態になります。

ただし、Hyperdriveのようにネットワーキングレベルの実装が必要なバインディングは事情が異なり、Viteでは正しく動作しません。この点は内容が独立しているので、別記事で詳しく扱います。

どちらを使うべきか

Alcogyでは、日常的な開発は基本的にVite（bun dev）で進めています。SvelteKitのコンポーネントを触っている時間が圧倒的に長く、HMRによる高速なフィードバックループの恩恵が大きいためです。

一方で、次のようなタイミングではwrangler devに切り替えます。

  • デプロイ前に、ビルド成果物が本番相当のランタイムで問題なく動くか最終確認したいとき
  • ネットワーキング系バインディング（Hyperdriveなど）を使う機能を実装・検証するとき
  • nodejs_compatまわりの互換性問題など、workerd固有の挙動を疑っているとき

普段はViteの速さで開発し、要所要所でwrangler devによる本番相当の確認を挟む、という使い分けが基本になります。