wrangler 4.x

Complete instructions

Wrangler 4.x development contracts

The previous delivery recorded four programmatic API examples against Wrangler 4.129.1 on 2026-09-07. That evidence belongs to that archived delivery; it does not establish that those exports exist in earlier 4.x releases.

Start from the installed version and configuration

Use the project's package scripts and local Wrangler dependency. Check its version and relevant help before selecting flags. Wrangler 4.90.1 does not expose the newer createTestHarness API; importing it from this version fails. An unstable programmatic helper needs the installed package's actual signature.

Use the same explicit config and environment for type generation and execution. For frameworks that generate Wrangler config, change the source rather than editing generated output. Preserve the project's compatibility date and flags unless the task includes reviewing and testing a runtime migration.

Generate and check binding types

wrangler types worker-configuration.d.ts --config wrangler.json
wrangler types worker-configuration.d.ts --config wrangler.json --check

Generated Env describes configured variables and bindings. Include the generated file in the Worker TypeScript project. Keep custom source-owned interfaces separate; do not hand-edit generated bindings or duplicate them with any.

--strict-vars defaults to true and produces literal or union types for variables. Use false when intentionally requesting general string types. --check detects changed generation inputs; it does not type-check application code or verify the generated declaration body. Run both checks when changing bindings.

An unknown binding or invalid KV value should fail compilation. A configuration change should make types --check fail until types are regenerated. A passing hash check cannot prove that the referenced remote resource exists.

Exercise the configured local runtime

For a local integration fixture on Wrangler 4.90.1:

import { unstable_dev } from "wrangler";

const worker = await unstable_dev("worker.js", {
  config: "wrangler.json",
  local: true,
  persist: false,
});
try {
  const response = await worker.fetch("/");
  if (!response.ok) throw new Error(`Worker returned ${response.status}`);
} finally {
  await worker.stop();
}

Test a valid request, rejection before writes, and read-after-write through the Worker handler. Dispose the runner even when an assertion fails. Give fixtures their own configuration and state; a local Worker can still use remote bindings when configured that way, so inspect binding targets rather than trusting the word "local" alone.

getPlatformProxy is a Node helper for accessing bindings and needs dispose(). Calling a handler directly with its proxied env does not execute that handler inside workerd. Use a local Worker runner when making runtime claims.

Keep remote operations task-scoped

Neither local type generation nor local integration testing requires an account login, deployment, or production data access. For requested remote work, identify the intended config, environment and resources first. A dry-run bundle validates packaging, not remote permissions or resource behavior. Secrets stay outside public configuration, source and command logs.

Sources

• Wrangler types and command reference
• Workers TypeScript configuration
• Cloudflare's official Wrangler skill