Wrangler

作者 cloudflareb052c32bab7d無授權條款3K 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫7 天前更新

Run or troubleshoot Wrangler CLI commands and configure Worker projects for local development, deployment, and Cloudflare resource management.

僅含說明DevOps & Cloud
AI 產生的概覽

指導執行與疑難排解 Wrangler CLI 指令,並設定 Cloudflare Worker 專案。

功能
此技能提供檢查 Worker 專案、取得最新 Wrangler 文件,以及套用設定或指令變更的說明。內容涵蓋本機開發、部署、環境、密鑰、繫結、回復與驗證步驟。它產出的是指引與設定修改,而非指令碼或產生的檔案。
適用情境
適用於使用 Wrangler 的 Cloudflare Workers 專案,例如設定繫結或環境、部署、管理密鑰,或疑難排解 CLI 與身分驗證問題。也適用於將應用程式移轉至 Workers 或驗證部署變更的情境。
執行需求
需要一個 Cloudflare Workers 專案,並透過專案的套件管理員在本機提供 Wrangler;還需存取 Cloudflare 文件(可選透過 Cloudflare MCP docs 工具)以及用於取得文件之網路存取。涉及帳戶或部署操作時可能需要 Cloudflare 帳戶身分驗證。不隨附指令碼。

Wrangler CLI

Use the project's Wrangler version and retrieve the relevant documentation before writing commands or configuration. CLI flags and configuration fields change; do not rely on memorized examples.

Inspect the Project

  • Find the package manager, installed Wrangler version, package scripts, framework, and Wrangler config. Run commands through the project's scripts or package manager so they use its local version. Install dependencies using the existing lockfile when needed; do not silently upgrade Wrangler to match current docs. If Wrangler is not a dependency, follow the installation guide to add it locally.
  • Identify the config used by the build or deploy command, including framework-generated config. Edit its source rather than generated output.
  • Establish the target account, Worker, environment, and resource before running commands that change them. For data operations, determine whether the target is local or remote.

Retrieve What the Task Needs

Use the Cloudflare MCP docs tool if available, or fetch the relevant linked page directly. Follow links to the specific command or product involved; avoid loading the entire reference. If a page moves, rediscover it through the Wrangler command index or Cloudflare docs search.

TaskSource
Discover commands and flags, including resource management, deployments, rollback, and diagnosticsProject-local wrangler --help and wrangler <command> --help; command reference
Edit config or add a bindingInstalled wrangler/config-schema.json (usually under node_modules); configuration reference
Deploy a framework applicationFramework guides; follow the guide for the project's existing framework and adapter
Migrate an application to Workers when requestedPages to Workers; Vercel to Workers
Configure staging or productionEnvironments
Set secrets locally, in CI, or on a deployed WorkerSecrets
Generate binding and runtime typesTypeScript
Run locally or choose a testing approachLocal development; testing
Diagnose authentication or select an accountGeneral commands, including whoami; authentication profiles
Deploy an unauthenticated prototypeClaim deployments for eligibility, expiry, and claim URL handling; use a permanent account for production or CI

Use installed help and schema to check whether documented features exist in the project's version. If a required feature needs an upgrade, make that dependency explicit. If retrieval is unavailable, state the gap and use available local evidence rather than inventing syntax.

Apply the Change

  • Prefer wrangler.jsonc for new config. Set a new project's compatibility date to today; review runtime changes and test when advancing an existing project's date. Preserve existing project conventions and avoid incidental format migrations.
  • Check environment inheritance before adding bindings or variables. Some fields must be specified separately for each environment; a working default config does not establish that staging is configured.
  • With the Cloudflare Vite plugin, select the environment via CLOUDFLARE_ENV at dev or build time. Deploy the resulting build; setting an environment at deploy time does not retarget its flattened config. See Vite environments.
  • Reconcile dashboard changes with the config before deploying: Wrangler can overwrite dashboard variables and routes. When binding existing resources, verify their identifiers; omitted identifiers can trigger automatic provisioning.
  • Distinguish local simulation from remote bindings during development. A locally running Worker can still access real resources; check the selected bindings before testing writes.
  • Keep secret values out of command arguments, source code, and logs. Use the documented interactive input or protected file/stdin mechanism for the command. Local secret files must be ignored by version control and are not automatically uploaded as deployed secrets. For missing local secrets, check file precedence and any secrets.required declaration in the secrets docs.
  • Treat wrangler secret put and secret delete as deployments: they create a version and deploy it immediately. Use the documented wrangler versions secret workflow when the change must be staged.
  • Before a rollback, check rollback limitations: connected resources and their data are not rolled back with Worker code.

Validate

After changing config or bindings in a TypeScript project, regenerate types with the project's wrangler types command rather than hand-editing generated declarations. Run the relevant existing typecheck or tests.

For deployment changes, use the project's build workflow and wrangler deploy --dry-run where supported, with the intended config and environment. A successful dry run checks the build and packaging; it does not prove remote resources or runtime behavior work. Use task-specific local or remote checks as appropriate to the requested work.

Report what changed, the target environment, checks performed, and any unresolved validation gaps. Link the documentation used when the result depends on current command or configuration behavior.

來源與署名

來源:cloudflare/skills位於skills/wrangler提交b052c32

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架