Cloudflare Docs
View RSS feed
Edit this page on GitHub
Set theme to dark (⇧+D)

Wrangler Changelog

​​ 2024-02-29

​​ 3.30.1

​​ 2024-02-27

​​ 3.30.0

​​ 2024-02-22

​​ 3.29.0

​​ 2024-02-20

​​ 3.28.4

​​ 2024-02-16

​​ 3.28.3

​​ 2024-02-13

​​ 3.28.2

​​ 2024-02-09

​​ 3.28.1

​​ 2024-02-08

​​ 3.28.0

  • #4499 cf9c029b Thanks @penalosa! - feat: Support runtime-agnostic polyfills

    Previously, Wrangler treated any imports of node:* modules as build-time errors (unless one of the two Node.js compatibility modes was enabled). This is sometimes overly aggressive, since those imports are often not hit at runtime (for instance, it was impossible to write a library that worked across Node.JS and Workers, using Node packages only when running in Node). Here’s an example of a function that would cause Wrangler to fail to build:

    export function randomBytes(length: number) {
    if (navigator.userAgent !== "Cloudflare-Workers") {
    return new Uint8Array(require("node:crypto").randomBytes(length));
    } else {
    return crypto.getRandomValues(new Uint8Array(length));

    This function should work in both Workers and Node, since it gates Node-specific functionality behind a user agent check, and falls back to the built-in Workers crypto API. Instead, Wrangler detected the node:crypto import and failed with the following error:

    ✘ [ERROR] Could not resolve "node:crypto"
          5 │ ... return new Uint8Array(require('node:crypto').randomBytes(length));
            ╵                                   ~~~~~~~~~~~~~
      The package "node:crypto" wasn't found on the file system but is built into node.
      Add "node_compat = true" to your wrangler.toml file to enable Node.js compatibility.

    This change turns that Wrangler build failure into a warning, which users can choose to ignore if they know the import of node:* APIs is safe (because it will never trigger at runtime, for instance):

    ▲ [WARNING] The package "node:crypto" wasn't found on the file system but is built into node.
      Your Worker may throw errors at runtime unless you enable the "nodejs_compat"
      compatibility flag. Refer to for more details.
      Imported from:
       - src/randomBytes.ts

    However, in a lot of cases, it’s possible to know at build time whether the import is safe. This change also injects navigator.userAgent into esbuild’s bundle settings as a predefined constant, which means that esbuild can tree-shake away imports of node:* APIs that are guaranteed not to be hit at runtime, supressing the warning entirely.

  • #4926 a14bd1d9 Thanks @dario-piotrowicz! - feature: add a cf field to the getBindingsProxy result

    Add a new cf field to the getBindingsProxy result that people can use to mock the production cf (IncomingRequestCfProperties) object.


    const { cf } = await getBindingsProxy();
    console.log(`country = ${}; colo = ${cf.colo}`);
  • #4931 321c7ed7 Thanks @dario-piotrowicz! - fix: make the entrypoint optional for the types command

    Currently running wrangler types against a wrangler.toml file without a defined entrypoint (main value) causes the command to error with the following message:

    ✘ [ERROR] Missing entry-point: The entry-point should be specified via the command line (e.g. `wrangler types path/to/script`) or the `main` config field.

    However developers could want to generate types without the entrypoint being defined (for example when using getBindingsProxy), so these changes make the entrypoint optional for the types command, assuming modules syntax if none is specified.

  • #4867 d637bd59 Thanks @RamIdeas! - fix: inflight requests to UserWorker which failed across reloads are now retried

    Previously, when running wrangler dev, requests inflight during a UserWorker reload (due to config or source file changes) would fail.

    Now, if those inflight requests are GET or HEAD requests, they will be reproxied against the new UserWorker. This adds to the guarantee that requests made during local development reach the latest worker.

  • #4928 4a735c46 Thanks @sdnts! - fix: Update API calls for Sippy’s endpoints

  • #4938 75bd08ae Thanks @rozenmd! - fix: print wrangler banner at the start of every d1 command

    This PR adds a wrangler banner to the start of every D1 command (except when invoked in JSON-mode)

    For example:

     ⛅️ wrangler 3.27.0
  • #4953 d96bc7dd Thanks @mrbbot! - fix: allow port option to be specified with unstable_dev()

    Previously, specifying a non-zero port when using unstable_dev() would try to start two servers on that port. This change ensures we only start the user-facing server on the specified port, allow unstable_dev() to startup correctly.

​​ 2024-02-06

​​ 3.27.0

​​ 2024-01-31

​​ 3.26.0

​​ 2024-01-26

​​ 3.25.0