Skip to content
Cloudflare Docs

Wrangler

2025-01-17

3.103.2

Patch Changes

  • #7804 16a9460 Thanks @vicb! - fix(wrangler): use require.resolve to resolve unenv path

2025-01-16

3.103.1

Patch Changes

2025-01-16

3.103.0

Minor Changes

  • #5086 8faf2c0 Thanks @dario-piotrowicz! - add --strict-vars option to wrangler types

    add a new --strict-vars option to wrangler types that developers can (by setting the flag to false) use to disable the default strict/literal types generation for their variables

    opting out of strict variables can be useful when developers change often their vars values, even more so when multiple environments are involved

    Example

    With a toml containing:

    [vars]
MY_VARIABLE = "production_value"
MY_NUMBERS = [1, 2, 3]

[env.staging.vars]
MY_VARIABLE = "staging_value"
MY_NUMBERS = [7, 8, 9]

    the wrangler types command would generate the following interface:

    interface Env {
        MY_VARIABLE: "production_value" | "staging_value";
        MY_NUMBERS: [1,2,3] | [7,8,9];
}

    while wrangler types --strict-vars=false would instead generate:

    interface Env {
        MY_VARIABLE: string;
        MY_NUMBERS: number[];
}

    (allowing the developer to easily change their toml variables without the risk of breaking typescript types)

Patch Changes

  • #7720 902e3af Thanks @vicb! - chore(wrangler): use the unenv preset from @cloudflare/unenv-preset

  • #7760 19228e5 Thanks @vicb! - chore: update unenv dependency version

  • #7735 e8aaa39 Thanks @penalosa! - Unwrap the error cause when available to send to Sentry

  • #5086 8faf2c0 Thanks @dario-piotrowicz! - fix: widen multi-env vars types in wrangler types

    Currently, the type generated for vars is a string literal consisting of the value of the variable in the top level environment. If multiple environments are specified this wrongly restricts the type, since the variable could contain any of the values from each of the environments.

    For example, given a wrangler.toml containing the following:

    [vars]
MY_VAR = "dev value"

[env.production.vars]
MY_VAR = "prod value"

    running wrangler types would generate:

    interface Env {
  MY_VAR: "dev value";
}

    making typescript incorrectly assume that MY_VAR is always going to be "dev value"

    after these changes, the generated interface would instead be:

    interface Env {
  MY_VAR: "dev value" | "prod value";
}

  • #7733 dceb196 Thanks @emily-shen! - feat: pull resource names for provisioning from config if provided

    Uses database_name and bucket_name for provisioning if specified. For R2, this only happens if there is not a bucket with that name already. Also respects R2 jurisdiction if provided.

  • Updated dependencies []:

2025-01-14

3.102.0

Minor Changes

Patch Changes

  • #7750 df0e5be Thanks @andyjessop! - bug: Removes the (local) tag on Vectorize bindings in the console output of wrangler dev, and adds-in the same tag for Durable Objects (which are emulated locally in wrangler dev).

  • #7732 d102b60 Thanks @Ankcorn! - fix pages secret bulk copy

  • #7706 c63f1b0 Thanks @penalosa! - Remove the server-based dev registry in favour of the more stable file-based dev registry. There should be no user-facing impact.

  • Updated dependencies [8e9aa40]:

2025-01-09

3.101.0

Minor Changes

  • #7534 7c8ae1c Thanks @cmackenzie1! - feat: Use OAuth flow to generate R2 tokens for Pipelines

  • #7674 45d1d1e Thanks @Ankcorn! - Add support for env files to wrangler secret bulk i.e. .dev.vars

    Run wrangler secret bulk .dev.vars to add the env file

    //.dev.vars
KEY=VALUE
KEY_2=VALUE

    This will upload the secrets KEY and KEY_2 to your worker

  • #7442 e4716cc Thanks @petebacondarwin! - feat: add support for redirecting Wrangler to a generated config when running deploy-related commands

    This new feature is designed for build tools and frameworks to provide a deploy-specific configuration, which Wrangler can use instead of user configuration when running deploy-related commands. It is not expected that developers of Workers will need to use this feature directly.

    Affected commands

    The commands that use this feature are:

    • wrangler deploy
    • wrangler dev
    • wrangler versions upload
    • wrangler versions deploy
    • wrangler pages deploy
    • wrangler pages build
    • wrangler pages build-env

    Config redirect file

    When running these commands, Wrangler will look up the directory tree from the current working directory for a file at the path .wrangler/deploy/config.json. This file must contain only a single JSON object of the form:

    { "configPath": "../../path/to/wrangler.json" }

    When this file exists Wrangler will follow the configPath (relative to the .wrangler/deploy/config.json file) to find an alternative Wrangler configuration file to load and use as part of this command.

    When this happens Wrangler will display a warning to the user to indicate that the configuration has been redirected to a different file than the user's configuration file.

    Custom build tool example

    A common approach that a build tool might choose to implement.

    • The user writes code that uses Cloudflare Workers resources, configured via a user wrangler.toml file.

      name = "my-worker"
main = "src/index.ts"
[[kv_namespaces]]
binding = "<BINDING_NAME1>"
id = "<NAMESPACE_ID1>"

      Note that this configuration points main at user code entry-point.

    • The user runs a custom build, which might read the wrangler.toml to find the entry-point:

      > my-tool build

    • This tool generates a dist directory that contains both compiled code and a new deployment configuration file, but also a .wrangler/deploy/config.json file that redirects Wrangler to this new deployment configuration file:

      - dist
  - index.js
    - wrangler.json
- .wrangler
  - deploy
      - config.json

      The dist/wrangler.json will contain:

      {
  "name": "my-worker",
  "main": "./index.js",
  "kv_namespaces": [
    { "binding": "<BINDING_NAME1>", "id": "<NAMESPACE_ID1>" }
  ]
}

      And the .wrangler/deploy/config.json will contain:

      {
  "configPath": "../../dist/wrangler.json"
}

  • #7685 9d2740a Thanks @vicb! - allow overriding the unenv preset.

    By default wrangler uses the bundled unenv preset.

    Setting WRANGLER_UNENV_RESOLVE_PATHS allow to use another version of the preset. Those paths are used when resolving the unenv module identifiers to absolute paths. This can be used to test a development version.

  • #7694 f3c2f69 Thanks @joshthoward! - Default wrangler d1 export to --local rather than failing

Patch Changes

2025-01-07

3.100.0

Minor Changes

  • #7604 6c2f173 Thanks @CarmenPopoviciu! - feat: Capture Workers with static assets in the telemetry data

    We want to measure accurately what this number of Workers + Assets projects running in remote mode is, as this number will be a very helpful data point down the road, when more decisions around remote mode will have to be taken.

    These changes add this kind of insight to our telemetry data, by capturing whether the command running is in the context of a Workers + Assets project.

    N.B. With these changes in place we will be capturing the Workers + Assets context for all commands, not just wrangler dev --remote.

Patch Changes