Skip to main content
The wrangler types command generates TypeScript type definitions from your Worker configuration, providing type safety for your Worker’s environment bindings.
wrangler types [path]
path
string
default:"worker-configuration.d.ts"
The path to the declaration file for the generated types

Options

--env-interface
string
default:"Env"
The name of the generated environment interface
--include-runtime
boolean
default:"true"
Include runtime types in the generated types
--include-env
boolean
default:"true"
Include Env types in the generated types
--strict-vars
boolean
default:"true"
Generate literal and union types for variables
--check
boolean
Check if the types at the provided path are up to date without regenerating them

Example

# Generate types with default settings
wrangler types

# Generate types to a specific file
wrangler types src/worker-env.d.ts

# Generate with custom interface name
wrangler types --env-interface MyEnv

# Generate only environment types (no runtime types)
wrangler types --include-runtime false

# Check if types are up to date
wrangler types --check

What Gets Generated

The wrangler types command generates TypeScript declarations for:

Environment Bindings

  • KV Namespaces - KVNamespace types for Key-Value stores
  • R2 Buckets - R2Bucket types for object storage
  • D1 Databases - D1Database types for SQL databases
  • Durable Objects - Typed DurableObjectNamespace with your class
  • Service Bindings - Service or Fetcher types for Worker-to-Worker communication
  • AI Bindings - Ai types for AI models
  • Workflows - Workflow types with typed parameters
  • Analytics Engine - AnalyticsEngine types
  • Queues - Queue types for message queues

Variables and Secrets

  • Vars - Typed based on their values (string, number, boolean, object)
  • Secrets - Always typed as string

Runtime Types

When --include-runtime is true (default), generates types for:
  • Workers Runtime APIs
  • Request/Response types
  • Compatible Node.js APIs (when using nodejs_compat)

Usage in Your Worker

After generating types, use them in your Worker:
index.ts
// The Env interface is automatically available
export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    // env is now fully typed with your bindings
    const value = await env.MY_KV.get('key');
    const result = await env.MY_DB.prepare('SELECT * FROM users').all();
    
    return new Response('Hello');
  }
};

Configuration Example

Given this wrangler.json configuration:
wrangler.json
{
  "name": "my-worker",
  "main": "src/index.ts",
  "compatibility_date": "2024-01-01",
  "kv_namespaces": [
    { "binding": "MY_KV", "id": "abc123" }
  ],
  "r2_buckets": [
    { "binding": "MY_BUCKET", "bucket_name": "my-bucket" }
  ],
  "d1_databases": [
    { "binding": "MY_DB", "database_id": "def456" }
  ],
  "vars": {
    "ENVIRONMENT": "production",
    "MAX_RETRIES": 3,
    "FEATURE_FLAGS": { "newUI": true }
  }
}
Running wrangler types generates:
worker-configuration.d.ts
/* eslint-disable */
// Generated by Wrangler by running `wrangler types` (hash: abc123def456)

declare namespace Cloudflare {
  interface Env {
    MY_KV: KVNamespace;
    MY_BUCKET: R2Bucket;
    MY_DB: D1Database;
    ENVIRONMENT: "production";
    MAX_RETRIES: 3;
    FEATURE_FLAGS: {"newUI":true};
  }
}

interface Env extends Cloudflare.Env {}

// Begin runtime types
// ... Workers runtime types ...

Multi-Environment Types

When you have multiple environments defined in your configuration, wrangler types generates separate interfaces for each:
wrangler.json
{
  "name": "my-worker",
  "kv_namespaces": [
    { "binding": "SHARED_KV", "id": "shared-123" }
  ],
  "env": {
    "staging": {
      "kv_namespaces": [
        { "binding": "STAGING_KV", "id": "staging-123" }
      ]
    },
    "production": {
      "kv_namespaces": [
        { "binding": "PROD_KV", "id": "prod-123" }
      ]
    }
  }
}
Generates:
declare namespace Cloudflare {
  interface EnvStaging {
    STAGING_KV: KVNamespace;
    SHARED_KV: KVNamespace;
  }
  
  interface EnvProduction {
    PROD_KV: KVNamespace;
    SHARED_KV: KVNamespace;
  }
  
  interface Env {
    SHARED_KV: KVNamespace;
    STAGING_KV?: KVNamespace;
    PROD_KV?: KVNamespace;
  }
}

TypeScript Configuration

Add the generated types to your tsconfig.json:
tsconfig.json
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ES2022",
    "lib": ["ES2022"],
    "types": [
      "@cloudflare/workers-types"
    ]
  },
  "include": [
    "src/**/*",
    "worker-configuration.d.ts"
  ]
}

Workflow Integration

1

Generate types initially

wrangler types
2

Add to version control

git add worker-configuration.d.ts
git commit -m "Add generated Worker types"
3

Regenerate after config changes

Whenever you modify your wrangler.json (add bindings, change vars, etc.), regenerate types:
wrangler types
4

Verify types are current in CI

Add a check to your CI pipeline:
# This will fail if types are out of date
wrangler types --check
5

Use types in your code

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // Full type safety for all bindings
    const data = await env.MY_KV.get('key');
    return new Response(data);
  }
};

Best Practices

  • Regenerate after configuration changes - Run wrangler types whenever you modify wrangler.json
  • Commit generated types - Check the generated .d.ts file into version control
  • Use in CI - Add wrangler types --check to your CI pipeline to ensure types are up to date
  • Custom interface names - Use --env-interface if you need to avoid naming conflicts
  • Keep types location consistent - Use the same path across your team

Strict Vars Mode

When --strict-vars is enabled (default), variables are typed with their exact values:
// With --strict-vars (default)
ENVIRONMENT: "production" | "staging"  // literal union type
MAX_RETRIES: 3                          // literal number

// With --strict-vars false
ENVIRONMENT: string                     // generic string
MAX_RETRIES: number                     // generic number
Strict mode provides better type safety by catching typos and invalid values at compile time.

Module Types

Types are also generated for module imports defined in your configuration:
wrangler.json
{
  "rules": [
    { "type": "CompiledWasm", "globs": ["**/*.wasm"] },
    { "type": "Text", "globs": ["**/*.txt"] }
  ]
}
Generates:
declare module "*.wasm" {
  const value: WebAssembly.Module;
  export default value;
}

declare module "*.txt" {
  const value: string;
  export default value;
}

Troubleshooting

Types out of date warning during wrangler dev:
Your types might be out of date. Re-run `wrangler types` to ensure your types are correct.
Solution: Run wrangler types to regenerate. Non-Wrangler .d.ts file exists error:
A non-Wrangler worker-configuration.d.ts already exists
Solution: Rename the existing file or use a different path with wrangler types custom-path.d.ts. Path doesn’t point to a declaration file:
The provided output path 'types.ts' does not point to a declaration file
Solution: Use .d.ts extension: wrangler types types.d.ts.

Build docs developers (and LLMs) love