cloudflare/workers-sdk wrangler@3.101.0

on GitHub

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

• #7456 ff4e77e Thanks @andyjessop! - chore: removes --experimental-versions flag, as versions is now GA.

• #7712 6439347 Thanks @penalosa! - Remove CF-Connecting-IP for requests to the edge preview

• #7703 e771fe9 Thanks @petebacondarwin! - include the top level Worker name in the parsed config structure

• #7576 773bda8 Thanks @cmackenzie1! - Remove defaults for batch-max-* pipeline parameters and define value ranges

• Updated dependencies [2c76887, 78bdec5]:

  • miniflare@3.20241230.1