非推奨

Wrangler のバージョン間の違い、特に非推奨と破壊的変更を確認します。

Workers Sites の使用は非推奨です。代わりに Workers Static Assets へ移行してください。Wrangler での Workers Sites のサポートは、将来のバージョンで削除されます。

Wrangler 設定の legacy_env プロパティで有効にする Service Environments ↗ の使用は非推奨です。代わりに Wrangler Environments へ移行してください。Wrangler での Service Environments のサポートは、将来のバージョンで削除されます。

次のコマンドは、Wrangler v3 時点で非推奨です。将来のバージョンで完全に削除されます。

wrangler generate コマンドは非推奨ですが、v3 ではまだ使えます。wrangler generate は v4 で完全に削除されます。

新しい Workers および Pages プロジェクトには npm create cloudflare@latest を使います。

wrangler publish コマンドは非推奨ですが、v3 ではまだ使えます。wrangler publish は v4 で完全に削除されます。

Workers のデプロイには npx wrangler deploy を使います。

wrangler pages publish コマンドは非推奨ですが、v3 ではまだ使えます。wrangler pages publish は v4 で完全に削除されます。

Pages のデプロイには wrangler pages deploy を使います。

代わりに wrangler --version で、いまの Wrangler のバージョンを確認します。

v3 の wrangler dev はデフォルトでローカルなので、このオプションは不要です。

v3 の wrangler dev はデフォルトでローカルなので、このオプションは不要です。

wrangler dev はデフォルトでデータを自動的に永続化するため、このオプションは不要です。

これらのオプションがあると、wrangler pages dev が静的アセット配信における本番の挙動を正確に再現できません。そのため非推奨です。Wrangler に別の上流 dev サーバーへプロキシさせるのではなく、静的アセットをディレクトリへビルドし、wrangler pages dev <directory> でそのディレクトリを指定すると、より正確な挙動を再現できます。

Workers assets へ移行 ↗ してください。

代わりに nodejs_compat 互換フラグ ↗ を使います。レガシーな node_compat ポリフィルの機能と、ネイティブ実装の Node.js API の両方が含まれます。

Workers Standard Pricing のロールアウト ↗ 以降、効果はありません。

Wrangler v2 では、設定用の新しいフィールドと、Worker の開発・デプロイ向けの新機能が追加され、一部の冗長なフィールドは非推奨になりました。

• wrangler.toml は必須ではなくなりました。
• dev と publish は CLI 引数を受け付けます。
• tail は任意の Worker 名で実行できます。
• init はプロジェクトのボイラープレートを作成します。
• vars の JSON バインディング。
• wrangler dev のローカルモード。
• モジュールシステム（modules 形式と service worker 形式の両方の Worker）。
• DevTools。
• TypeScript サポート。
• 開発環境をインターネット上で共有できます。
• より広いプラットフォーム互換性。
• 開発者向けホットキー。
• 設定の検証の改善。

次の動画では、Wrangler v2 の主な変更を説明し、作業の流れを速くする方法を紹介します。

必須ではなくなったよくあるフィールドは、次の一覧を参照してください。

• type は不要になりました。Wrangler が正しいプロジェクトタイプを自動で推測します。
• zone_id は不要になりました。ルートから直接導出できます。
• build.upload.format は使われません。形式はコードから自動で推測されます。
• build.upload.main と build.upload.dir は不要になりました。Worker のエントリーポイントになるトップレベルの main フィールドを使います。
• site.entry-point は不要になりました。エントリーポイントは main フィールドで指定します。
• webpack_config と webpack プロパティはサポートされません。Wrangler バージョン 1 の webpack プロジェクトを移行する を参照してください。 サポートされなくなった Wrangler v1 のコマンドは次のとおりです。
• wrangler preview — ローカル環境で Worker を実行するには wrangler dev コマンドを使います。
• wrangler generate — スターターテンプレートを使いたい場合は、GitHub リポジトリをクローンして手動で初期化します。
• wrangler route — ルートは Wrangler 設定ファイル で定義します。
• wrangler report — バグを見つけた場合は Wrangler issues ↗ で報告します。
• wrangler build — Worker のバンドル結果にアクセスしたい場合は wrangler deploy --outdir=path/to/output を使います。

次は、Wrangler 設定ファイル に追加できる新しいフィールドです。

• main: string、任意

  main フィールドは、Worker のエントリーポイントを指定します。従来の service worker 形式でも、推奨される新しい modules 形式でも構いません。エントリーポイントは明示的に必須になり、main フィールドで設定するか、コマンドラインで直接渡せます（例: wrangler dev index.js）。このフィールドは、レガシーの build.upload.main フィールド（modules 形式の Worker にだけ適用）を置き換えます。

• rules: array、任意

  rules フィールドは、モジュールタイプとファイルパターンの対応の配列です。特定のファイルを JavaScript とは別に解釈するよう Wrangler に指示します。たとえば、テキストに近い内容をテキストファイルとして読む場合や、コンパイル済み WASM をすぐにインスタンス化して実行できるものとして扱う場合に便利です。これらのルールは、従来の service worker 形式と新しい modules 形式の両方の Worker に適用できます。このフィールドは、レガシーの build.upload.rules フィールド（modules 形式の Worker にだけ適用）を置き換えます。

以前は必須だった設定フィールドのうち、特定の状況では任意になったものがいくつかあります。推測されるか、最適化として追加できます。Wrangler v2 では、開始時に必須のフィールドはなくなりました。必要になったときに、設定を少しずつ追加できます。

• name: string

  name 設定フィールドは、wrangler dev および wrangler kv:* コマンドでは不要になりました。さらに、--name <name> としてコマンドライン引数でも渡せます。wrangler deploy では、いまも必須です。

• account_id: string

  account_id フィールドは、どのコマンドでも必須ではありません。関連するコマンドは、ログイン済みかを確認し、未ログインならログインを求めます。ログイン後はアカウント ID を使い、ログインセッションが切れるまで再確認しません。アカウント ID が複数ある場合は、選ぶための一覧が表示されます。

  Wrangler ファイル、または環境変数 CLOUDFLARE_ACCOUNT_ID で account_id を設定することもできます。起動が速くなり、ID が複数あるときの選択肢一覧を回避できます。対話的にログインできない場合は、環境変数 CLOUDFLARE_API_TOKEN も便利です。詳細は CI/CD での実行 を参照してください。

• workers_dev boolean、デフォルト: ルートがないときは true

  workers_dev フィールドは、Worker を *.workers.dev サブドメインへ公開することを示します。たとえば、Worker 名が my-worker で、以前設定した *.workers.dev サブドメインが username の場合、Worker は my-worker.username.workers.dev.com へ公開されます。このフィールドは必須ではなく、route または routes が未設定のときはデフォルトで true です。ルートがあるときはデフォルトで false です。*.workers.dev サブドメインにもルートにも公開したくない場合は、workers_dev を false にします。Worker をスタンドアロンのサービスとして公開し、（services で）別の Worker からだけアクセスできるようにするときに便利です。

いくつかの設定フィールドは非推奨ですが、いまのところ存在しても破壊的変更にはなりません。警告メッセージを読み、新しい設定へ移行してください。将来のバージョンで削除され、動作しなくなります。

• zone_id: string、非推奨

  zone_id フィールドは非推奨で、将来のリリースで削除されます。いまは route / routes から、また wrangler dev を使うときは任意で dev.host から推測されます。これにより、1 つの Worker を複数ドメインへデプロイしやすくなります。

• build.upload: object、非推奨

  build.upload フィールドは非推奨で、将来のリリースで削除されます。使うと警告が出て、警告を消すための設定ファイルの書き換え方法が示されます。

  • build.upload.main / build.upload.dir は main フィールドに置き換わり、service worker 形式と modules 形式の両方の Worker に適用されます。
  • build.upload.rules は rules フィールドに置き換わり、service worker 形式と modules 形式の両方の Worker に適用されます。
  • build.upload.format は指定不要になり、wrangler が自動で推測します。

いくつかの設定フィールドは非推奨で、期待どおりには動きません。エラーメッセージを読み、新しい設定へ移行してください。

• site.entry-point: string、非推奨

  site.entry-point 設定は、[site] 設定がある Worker のエントリーポイントを指定するために使われていました。トップレベルの main フィールドに置き換わっています。

• type: rust | javascript | webpack、非推奨

  type 設定は Worker の種類を指定するために使われていました。冗長になり、いまは使い方から推測されます。type = "webpack"（および任意の webpack_config フィールド）を使っていた場合は、webpack 移行ガイド を読み、プロジェクトを変更してカスタムビルドを使ってください。

次のコマンドは、Wrangler v2 時点で非推奨です。

wrangler build コマンドは、Worker のビルドには使えなくなりました。

同等の機能は wrangler publish --dry-run --outdir=path/to/build で実現できます。

wrangler config コマンドは、API トークンでの認証には使えなくなりました。

OAuth 認証の管理には wrangler login / wrangler logout を使うか、環境変数 CLOUDFLARE_API_TOKEN で API トークンを渡します。

wrangler preview コマンドは、Worker の一時的なプレビューインスタンスの作成には使えなくなりました。

開発中に Worker を試すには、wrangler dev を使ってください。

wrangler subdomain コマンドは、workers.dev サブドメインの作成には使えなくなりました。

workers.dev サブドメインは、Workers & Pages > 対象の Worker を選択 > Your subdomain > Change で作成します。

wrangler route コマンドは、Worker のルート設定には使えなくなりました。

ルートは Wrangler 設定ファイル で指定します。

• Cloudflare ダッシュボードで定義したルートは、Wrangler で定義したルートと並べて追加されません。Wrangler で定義したルートは、wrangler.toml の route または routes キーです。両方がある場合、有効なのは wrangler.toml で定義したルートだけです。ルートを Cloudflare ダッシュボードだけで管理するには、Wrangler ファイルから route と routes キーを削除し、workers_dev = false を追加します。

• Wrangler は、wrangler dev を実行したディレクトリの index.js を、Worker のエントリーポイントとして使わなくなります。main 設定フィールドを使うか、コマンドライン引数として明示的に渡します（例: wrangler dev index.js）。

• Wrangler は、パスとして表されていない裸の指定子を、ファイル名とはみなさなくなります。たとえば、次のようなフォルダーがあるとします。

  project
  ├── index.js
  └── some-dependency.js

  index.js の内容が次の場合です。

  import SomeDependency from "some-dependency.js";
  
  addEventListener("fetch", (event) => {
    // ...
  });

  Wrangler v1 は import SomeDependency from "some-dependency.js"; をファイル some-dependency.js に解決していました。Wrangler v2 でも動きますが、非推奨の警告も出ます。将来はエラーで失敗します。代わりに、相対パスであることを示すようにインポートを書き換えてください。

  - import SomeDependency from "some-dependency.js";
  + import SomeDependency from "./some-dependency.js";