Version Packages

[workers-devprod]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@cloudflare/config@0.3.0

Minor Changes

• #14724 a50f73a Thanks @jamesopstad! - Add a settings export to the experimental cloudflare.config.ts config

  Account-level settings (accountId, complianceRegion) now live in a dedicated, named settings export authored via defineSettings, rather than on the Worker config. A cloudflare.config.ts can export at most one settings object; the Worker itself is the default export.

  // cloudflare.config.ts
  import { defineSettings, defineWorker } from "wrangler/experimental-config";
  import * as entrypoint from "./src/index.ts" with { type: "cf-worker" };
  
  export const settings = defineSettings({
  	accountId: "<your-account-id>",
  });
  
  export default defineWorker({
  	name: "my-worker",
  	entrypoint,
  	compatibilityDate: "2026-05-18",
  });

  This is only used behind the experimental new-config path (wrangler --experimental-new-config and the @cloudflare/vite-plugin experimental.newConfig option).

@cloudflare/deploy-helpers@0.6.0

Minor Changes

• #14471 f03b108 Thanks @DiogoSantoss! - Apply Email Routing addresses during Worker trigger deployment

  Worker trigger deployment now reconciles the Worker's Email Routing rules with the top-level addresses config. This runs for wrangler deploy, wrangler triggers deploy, and clients of @cloudflare/deploy-helpers. After the Worker uploads, or when wrangler triggers deploy runs after a version promotion, the deploy helper asks the Email Routing API for a plan, renders the changes grouped by zone (+ added, ~ updated, - deleted, ! conflict), prompts once for destructive changes in interactive mode, and applies accepted changes through the per-zone rule endpoints. Purely additive plans apply without a prompt, while non-interactive destructive plans fail without modifying rules.

Patch Changes

• #14744 a0a091b Thanks @penalosa! - Drop the "Experimental:" prefix from the resource provisioning header now that automatic provisioning is generally available. The deploy output now reads The following bindings need to be provisioned:.

• Updated dependencies [a6c214f, 34430b3]:

  • @cloudflare/workers-utils@0.27.1
  • miniflare@4.20260714.1
  • @cloudflare/cli-shared-helpers@0.1.16

miniflare@4.20260714.1

Minor Changes

• #14742 34430b3 Thanks @pombosilva! - Add support for redacting sensitive Workflows step output in local dev.

  Steps configured with sensitive: "output" now have their output redacted to [REDACTED] in step logs and step-output responses when running Workflows locally, matching production behavior. The real value is still passed to downstream steps, and step errors are never redacted.

@cloudflare/vite-plugin@1.46.0

Minor Changes

• #14724 a50f73a Thanks @jamesopstad! - Add a settings export to the experimental cloudflare.config.ts config

  Account-level settings (accountId, complianceRegion) now live in a dedicated, named settings export authored via defineSettings, rather than on the Worker config. A cloudflare.config.ts can export at most one settings object; the Worker itself is the default export.

  // cloudflare.config.ts
  import { defineSettings, defineWorker } from "wrangler/experimental-config";
  import * as entrypoint from "./src/index.ts" with { type: "cf-worker" };
  
  export const settings = defineSettings({
  	accountId: "<your-account-id>",
  });
  
  export default defineWorker({
  	name: "my-worker",
  	entrypoint,
  	compatibilityDate: "2026-05-18",
  });

  This is only used behind the experimental new-config path (wrangler --experimental-new-config and the @cloudflare/vite-plugin experimental.newConfig option).

Patch Changes

• Updated dependencies [a0a091b, f03b108, deae171, 4e92e32, d1d6945, a0c8bb1, a50f73a, c82d96b, 34430b3, f75ae5d]:
  • wrangler@4.113.0
  • miniflare@4.20260714.1

wrangler@4.113.0

Minor Changes

• #14471 f03b108 Thanks @DiogoSantoss! - Apply Email Routing addresses during Worker trigger deployment

  Worker trigger deployment now reconciles the Worker's Email Routing rules with the top-level addresses config. This runs for wrangler deploy, wrangler triggers deploy, and clients of @cloudflare/deploy-helpers. After the Worker uploads, or when wrangler triggers deploy runs after a version promotion, the deploy helper asks the Email Routing API for a plan, renders the changes grouped by zone (+ added, ~ updated, - deleted, ! conflict), prompts once for destructive changes in interactive mode, and applies accepted changes through the per-zone rule endpoints. Purely additive plans apply without a prompt, while non-interactive destructive plans fail without modifying rules.

• #14679 deae171 Thanks @dario-piotrowicz! - Add exclude_packages option to dependencies_instrumentation configuration

  The dependencies_instrumentation config object now accepts an optional exclude_packages field — an array of package name patterns (with glob-style * wildcards) to exclude from the dependency metadata collected during deploy and version uploads.

  // wrangler.json
  {
    "dependencies_instrumentation": {
      "exclude_packages": ["@internal/*", "secret-tool"]
    }
  }

• #14721 4e92e32 Thanks @dmmulroy! - Support Artifacts sources when creating Queue event subscriptions

  wrangler queues subscription create now accepts the artifacts and artifacts.repo source types supported by the Cloudflare API.

• #13352 d1d6945 Thanks @penalosa! - Expand automatic resource provisioning to Queue, Dispatch Namespace, and Flagship bindings

  Deployments can now omit the resource name or ID for these bindings. Wrangler will inherit the existing binding on subsequent deploys, create a deterministically named resource automatically, or offer existing resources during an interactive deploy with automatic creation disabled.

• #14688 a0c8bb1 Thanks @NuroDev! - Print Local Explorer API details for headless agent-driven wrangler dev sessions

  When wrangler dev is started in a headless AI agent environment, Wrangler now prints the Local Explorer API URL and basic resource routes so agents can inspect local Workers and bindings without relying on the interactive UI.

• #14724 a50f73a Thanks @jamesopstad! - Add a settings export to the experimental cloudflare.config.ts config

  Account-level settings (accountId, complianceRegion) now live in a dedicated, named settings export authored via defineSettings, rather than on the Worker config. A cloudflare.config.ts can export at most one settings object; the Worker itself is the default export.

  // cloudflare.config.ts
  import { defineSettings, defineWorker } from "wrangler/experimental-config";
  import * as entrypoint from "./src/index.ts" with { type: "cf-worker" };
  
  export const settings = defineSettings({
  	accountId: "<your-account-id>",
  });
  
  export default defineWorker({
  	name: "my-worker",
  	entrypoint,
  	compatibilityDate: "2026-05-18",
  });

  This is only used behind the experimental new-config path (wrangler --experimental-new-config and the @cloudflare/vite-plugin experimental.newConfig option).

• #14742 34430b3 Thanks @pombosilva! - Add support for redacting sensitive Workflows step output in local dev.

  Steps configured with sensitive: "output" now have their output redacted to [REDACTED] in step logs and step-output responses when running Workflows locally, matching production behavior. The real value is still passed to downstream steps, and step errors are never redacted.

Patch Changes

• #14744 a0a091b Thanks @penalosa! - Drop the "Experimental:" prefix from the resource provisioning header now that automatic provisioning is generally available. The deploy output now reads The following bindings need to be provisioned:.

• #14448 c82d96b Thanks @GregBrimble! - Use the new PATCH APIs for versioned secret commands

  Wrangler now updates versioned Worker secrets by patching the latest Worker version instead of downloading the latest version contents and uploading a full replacement version. This avoids reconstructing Worker configuration in Wrangler, which should reduce bugs when Workers use less common features. For example, this avoids regressions like the previous placement preservation bug fixed in #13843.

• #14617 f75ae5d Thanks @martijnwalraven! - Derive nodejsCompatMode from the effective compatibility inputs in unstable_startWorker()

  The CLI computes the node-compat mode from the effective compatibility date and flags (args.* ?? parsedConfig.*), but the programmatic path used input.build.nodejsCompatMode raw — leaving it unset meant a worker's nodejs_compat flag (from its config file or from input-level compatibilityFlags) was silently ignored, so bundling failed to resolve node builtins that wrangler dev handles. startWorker now derives the mode the same way when the caller does not provide one: input-level compatibilityDate/compatibilityFlags first, then the resolved config, with no-bundle taken from the resolved build.bundle semantics. Passing an explicit null still disables it.

• Updated dependencies [34430b3]:

  • miniflare@4.20260714.1

@cloudflare/autoconfig@0.1.7

Patch Changes

• #14534 a330170 Thanks @petebacondarwin! - Preserve existing Nuxt modules when configuring a project for Cloudflare

  Configuring an existing Nuxt project whose nuxt.config.ts already declares a modules array previously overwrote that array when adding nitro-cloudflare-dev, dropping modules such as @nuxt/ui. Existing entries are now retained and the Cloudflare module is appended instead.

• Updated dependencies [a6c214f]:

  • @cloudflare/workers-utils@0.27.1
  • @cloudflare/cli-shared-helpers@0.1.16

@cloudflare/cli-shared-helpers@0.1.16

Patch Changes

• Updated dependencies [a6c214f]:
  • @cloudflare/workers-utils@0.27.1

create-cloudflare@2.70.13

Patch Changes

• #14759 947ad34 Thanks @dependabot! - Update dependencies of "create-cloudflare"

  The following dependency versions have been updated:

  Dependency	From	To
  @angular/create	22.0.6	22.0.7

• #14760 9ed6dc2 Thanks @dependabot! - Update dependencies of "create-cloudflare"

  The following dependency versions have been updated:

  Dependency	From	To
  sv	0.16.2	0.16.3

• #14534 a330170 Thanks @petebacondarwin! - Preserve existing Nuxt modules when adding Cloudflare configuration

  Scaffolding a Nuxt application whose nuxt.config.ts already declares a modules array (for example the ui starter, which registers @nuxt/ui and @nuxt/eslint) previously overwrote that array when adding nitro-cloudflare-dev, dropping the existing modules and breaking the build. Existing entries are now retained and the Cloudflare module is appended instead.

@cloudflare/pages-shared@0.13.159

Patch Changes

• Updated dependencies [34430b3]:
  • miniflare@4.20260714.1

@cloudflare/vitest-pool-workers@0.18.7

Patch Changes

• #14713 de34449 Thanks @allocsys! - Fix a non-ASCII path failure during the Miniflare WebSocket handshake: the MF-Vitest-Worker-Data header embedded the raw process.cwd() value, which threw a Latin-1/ASCII header encoding error when the workspace path contained non-ASCII characters (e.g. CJK characters) on Windows. The value is now percent-encoded on write and decoded on read, matching the fix applied to the module fallback redirect response.

• #14713 de34449 Thanks @allocsys! - Fix a runtime start-up failure ("No such module "cloudflare:test-internal"") when the project workspace path contains non-ASCII characters (e.g. CJK characters) on Windows. The module fallback service's redirect response set the target file path directly as an HTTP Location header value, but headers are restricted to the Latin-1/ASCII byte range, so any non-ASCII byte in the path caused header construction to throw. Such paths are now percent-encoded (and tagged with a sentinel prefix) before being used as a header value, and decoded again only for the values we encoded, so the round-trip is unambiguous and a workspace path containing a literal % is left untouched instead of being mis-decoded.

• #14739 5eac99e Thanks @Ankcorn! - Support testing Streaming Tail Workers in Vitest Pool Workers.

• #14763 538e867 Thanks @gianghungtien! - Treat webSocketMessage(), webSocketClose() and webSocketError() as optional Durable Object handlers

  The pool wraps each Durable Object class and installs a prototype method for every default handler before user code is loaded, so workerd always sees a handler and always dispatches. When the wrapped class didn't actually define one, the wrapper threw <ClassName> exported by <path> does not define a `webSocketClose()` method, even though deployed Workers silently ignore these events for classes that omit them. A hibernatable Durable Object defining only webSocketMessage() would log an uncaught TypeError on every close.

  These three handlers now no-op when absent, matching deployed behaviour. alarm() is unchanged and still reports a missing handler, since workerd rejects setAlarm() up front on a class without one.

• Updated dependencies [a0a091b, f03b108, deae171, 4e92e32, d1d6945, a0c8bb1, a50f73a, c82d96b, 34430b3, f75ae5d]:

  • wrangler@4.113.0
  • miniflare@4.20260714.1

@cloudflare/workers-auth@0.5.1

Patch Changes

• Updated dependencies [a6c214f]:
  • @cloudflare/workers-utils@0.27.1

@cloudflare/workers-utils@0.27.1

Patch Changes

• #14746 a6c214f Thanks @samarth70! - Return a clear error when observability is set to null

  validateObservability guarded only against undefined, so a null value (valid in JSON/JSONC config) passed the typeof value === "object" check and then threw TypeError: Cannot read properties of null (reading 'enabled') while validating the config. It now rejects null with the same "observability" should be an object but got null. diagnostic that the sibling cache validator already produces.

@cloudflare/runtime-types@0.0.4

Patch Changes

• Updated dependencies [34430b3]:
  • miniflare@4.20260714.1

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🟡 Release version bump is smaller than the change warrants

The change that adds the ability to test Streaming Tail Workers is being released as a bug-fix-level update (patch, 0.18.6→0.18.7 in packages/vitest-pool-workers/package.json:3) even though it introduces brand-new functionality, which the repository's own guidelines say must be a feature-level update.
Impact: Users receive a new capability under a version number that signals only bug fixes, hiding the new feature from anyone relying on version numbers to decide when to adopt changes.

Semver classification mismatch per REVIEW.md

The deleted changeset .changeset/fuzzy-tails-listen.md declared "@cloudflare/vitest-pool-workers": patch with description "Support testing Streaming Tail Workers in Vitest Pool Workers."

REVIEW.md "Semver Classification" states that adding "new API capabilities" and "behavior changes that add functionality" are Minor, and explicitly: "A changeset described as 'Support X' is adding a new feature (minor)". This change adds support for a new class of Workers to be tested, which is a new feature, so it should be classified as minor (i.e. 0.19.0), not patch. This affects both the version in packages/vitest-pool-workers/package.json:3 and the CHANGELOG heading added at packages/vitest-pool-workers/CHANGELOG.md:3.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[github-actions]

⚠️ Issues found

• .changeset/fuzzy-tails-listen.md: Should be minor instead of patch. "Support testing Streaming Tail Workers in Vitest Pool Workers" adds a new user-facing capability, which qualifies as a new feature. Compare with .changeset/fuzzy-dogs-listen.md ("Support Artifacts sources when creating Queue event subscriptions"), which correctly uses minor for a similar scope of change.

[pkg-pr-new]

@cloudflare/autoconfig

npm i https://pkg.pr.new/@cloudflare/autoconfig@14740

@cloudflare/config

npm i https://pkg.pr.new/@cloudflare/config@14740

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@14740

@cloudflare/deploy-helpers

npm i https://pkg.pr.new/@cloudflare/deploy-helpers@14740

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@14740

miniflare

npm i https://pkg.pr.new/miniflare@14740

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@14740

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@14740

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@14740

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@14740

@cloudflare/workers-auth

npm i https://pkg.pr.new/@cloudflare/workers-auth@14740

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@14740

@cloudflare/workers-utils

npm i https://pkg.pr.new/@cloudflare/workers-utils@14740

wrangler

npm i https://pkg.pr.new/wrangler@14740

commit: 114215f