Skip to content

Releases: cloudflare/workers-sdk

wrangler@4.123.0

Choose a tag to compare

@workers-devprod workers-devprod released this 13 Aug 16:11
c576a82

Minor Changes

  • #15113 b8fd112 Thanks @BSFishy! - Add local dev simulation for Cloudflare Access ctx.access.getIdentity()

    You can now configure a mock Cloudflare Access identity in wrangler.json so that ctx.access.getIdentity() returns it during local development.

    // wrangler.json
    {
      "access": {
        "dev": {
          "aud": "my-app-aud-tag",
          "identity": {
            "email": "user@example.com",
            "name": "Test User"
          }
        }
      }
    }
  • #15152 f0f2054 Thanks @GregBrimble! - [private beta]: Updates the --ignore-defaults flag to --ignore-base-config on wrangler preview commands.

    --ignore-base-config now only takes effect on Preview creation, rather than on each deployment, since Preview base configuration is now copy-on-create rather than inherit-on-deploy.

  • #14872 339509d Thanks @dario-piotrowicz! - Add automatic update prompts for out-of-date Cloudflare agent skills

    When Cloudflare skills were previously installed by Wrangler and the upstream cloudflare/skills repository has newer content, Wrangler now offers to update them after eligible commands complete.

    To reduce prompt fatigue, the update check only runs once a month (30 days since the last install or update). Declining suppresses the prompt until the next upstream change.

    When declining an update, Wrangler offers the option to permanently disable future update prompts. This preference is stored globally in ~/.wrangler/agents-skills-install.jsonc. The WRANGLER_NO_SKILLS_UPDATE_PROMPTS=true environment variable can also be used to suppress prompts. The --install-skills flag remains available regardless of these settings.

Patch Changes

create-cloudflare@2.72.0

Choose a tag to compare

@workers-devprod workers-devprod released this 13 Aug 16:10
c576a82

Minor Changes

  • #14896 7d4565d Thanks @scottbuscemi! - Make vinext the default Next.js scaffold, keep OpenNext as a variant

    create-cloudflare --framework=next now prompts for a Next.js adapter:

    • vinext (default / recommended) — scaffolds via create-vinext-app (vinext dev / vinext build / vinext-cloudflare deploy)
    • opennext — keeps the previous OpenNext remote template for projects that need standard next build output or a capability vinext does not support yet

    Non-interactive usage:

    npm create cloudflare@latest my-app -- --framework=next --variant=vinext
    npm create cloudflare@latest my-app -- --framework=next --variant=opennext

    -y / --accept-defaults selects vinext. This aligns C3 with the recommended Next.js-on-Workers path in the Cloudflare docs while preserving an opt-in OpenNext path.

Patch Changes

  • #15126 24ac4fd Thanks @edmundhung! - Use Wrangler 4 when installing Hello World template dependencies

    This avoids installing Wrangler 3 during initial scaffolding before Create Cloudflare upgrades the generated project to the latest Wrangler release.

@cloudflare/vitest-pool-workers@0.21.3

Choose a tag to compare

@workers-devprod workers-devprod released this 13 Aug 16:11
c576a82

Patch Changes

@cloudflare/vite-plugin@1.52.1

Choose a tag to compare

@workers-devprod workers-devprod released this 13 Aug 16:11
c576a82

Patch Changes

@cloudflare/runtime-types@0.0.14

Choose a tag to compare

@workers-devprod workers-devprod released this 13 Aug 16:10
c576a82

Patch Changes

@cloudflare/remote-bindings@0.0.12

Choose a tag to compare

@workers-devprod workers-devprod released this 13 Aug 16:11
c576a82

Patch Changes

@cloudflare/pages-shared@0.13.169

Choose a tag to compare

@workers-devprod workers-devprod released this 13 Aug 16:10
c576a82

Patch Changes

@cloudflare/deploy-helpers@0.7.0

Choose a tag to compare

@workers-devprod workers-devprod released this 13 Aug 16:10
c576a82

Minor Changes

  • #15152 f0f2054 Thanks @GregBrimble! - [private beta]: Updates the --ignore-defaults flag to --ignore-base-config on wrangler preview commands.

    --ignore-base-config now only takes effect on Preview creation, rather than on each deployment, since Preview base configuration is now copy-on-create rather than inherit-on-deploy.

Patch Changes

miniflare@5.20260811.1-alpha

Pre-release

Choose a tag to compare

@workers-devprod workers-devprod released this 13 Aug 16:11
c576a82

Minor Changes

  • #15113 b8fd112 Thanks @BSFishy! - Add local dev simulation for Cloudflare Access ctx.access.getIdentity()

    You can now configure a mock Cloudflare Access identity in wrangler.json so that ctx.access.getIdentity() returns it during local development.

    // wrangler.json
    {
      "access": {
        "dev": {
          "aud": "my-app-aud-tag",
          "identity": {
            "email": "user@example.com",
            "name": "Test User"
          }
        }
      }
    }

wrangler@4.122.0

Choose a tag to compare

@workers-devprod workers-devprod released this 12 Aug 14:20
e5d56e9

Minor Changes

  • #15123 d0c976c Thanks @dependabot! - Detect Node.js compatibility from the compatibility date, now that nodejs_compat is enabled by default

    As of compatibility date 2026-08-04, workerd enables the nodejs_compat and nodejs_compat_v2 compatibility flags by default. Previously these tools only treated Node.js compatibility as enabled when one of those flags was listed explicitly, so a Worker on a compatibility date of 2026-08-04 or later without the flag would get Node.js APIs from the runtime but no Node.js polyfills from the bundler, and process.env could be substituted with an empty object at build time. They now resolve these flags the same way workerd does, and honour no_nodejs_compat to opt out.

    To keep Node.js compatibility switched off on a newer compatibility date, specify both no_nodejs_compat and no_nodejs_compat_v2, since each flag has its own default.

    @cloudflare/vitest-pool-workers needs nodejs_compat_v2 for its own test runner, so it continues to override a project that opts out of it. On a compatibility date that enables the flag anyway, it now drops the opt-out rather than adding the flag back, which workerd would reject — previously this stopped such a project from running any tests at all.

    wrangler types also no longer attributes its @types/node suggestion to "the nodejs_compat flag", which it can now make for Workers that do not set the flag at all.

Patch Changes

  • #15123 d0c976c Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

    The following dependency versions have been updated:

    Dependency From To
    @cloudflare/workers-types ^5.20260804.1 ^5.20260811.1
    workerd 1.20260804.1 1.20260811.1
  • #15148 0b82b15 Thanks @jamesopstad! - Ignore a nodejs_compat compatibility flag that the compatibility date already enables

    workerd rejects a compatibility flag that its compatibility date enables by default, so a Worker configured with both a compatibility date of 2026-08-04 or later and nodejs_compat failed to start locally with "The compatibility flag nodejs_compat became the default as of 2026-08-04 so does not need to be specified anymore".

    The redundant nodejs_compat and nodejs_compat_v2 flags are now dropped when starting the runtime, which has no effect on the resulting Worker because the compatibility date enables both anyway. no_nodejs_compat and no_nodejs_compat_v2 still switch Node.js compatibility off, and a flag specified alongside its own opt-out is left alone so that workerd still reports those as contradictory.

  • #15123 d0c976c Thanks @dependabot! - Stop adding a redundant nodejs_compat flag to generated Wrangler configurations

    create-cloudflare and wrangler setup write today's date as the compatibility_date, and from 2026-08-04 that already enables nodejs_compat. Adding the flag as well made the generated project fail to start with "The compatibility flag nodejs_compat became the default as of 2026-08-04 so does not need to be specified anymore", so the flag is now only added for earlier compatibility dates.

    create-cloudflare also removes the flag when a template, or a framework's own scaffolder, already wrote it into a configuration that ends up using such a compatibility date, and still installs @types/node for these projects even though there is no longer a flag to detect them by.

    wrangler setup does the same for a wrangler.json(c) that is already in the project: it writes today's date over whatever date that configuration was written for, so a nodejs_compat it finds there is removed as part of writing the file.

  • #15142 3b02915 Thanks @penalosa! - Fix remote binding sessions reusing stale binding configurations

    Starting a new remote bindings session that reuses a Worker name no longer picks up the bindings from a previous session, which could cause Binding "..." not found errors.

  • Updated dependencies [d0c976c, d0c976c, 0b82b15, d0c976c, 90dd5e5]: