Skip to content

Version Packages - #15175

Merged
edmundhung merged 1 commit into
mainfrom
changeset-release/main
Aug 18, 2026
Merged

Version Packages#15175
edmundhung merged 1 commit into
mainfrom
changeset-release/main

Conversation

@workers-devprod

@workers-devprod workers-devprod commented Aug 13, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

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.6.0

Minor Changes

  • #15026 6529f0c Thanks @petebacondarwin! - Add a container option to exports.durableObject()

    Live Durable Object exports can now attach a container by name, matching the new container field in the Wrangler configuration format:

    import { defineWorker, exports } from "@cloudflare/config";

export default defineWorker({
  name: "my-worker",
  compatibilityDate: "2026-07-01",
  exports: {
    MyContainerDO: exports.durableObject({
      storage: "sqlite",
      container: "my-container",
    }),
  },
});

    Containers are only supported on the SQLite storage engine, so container is only offered alongside storage: "sqlite". Passing it with storage: "legacy-kv" is a type error rather than something only caught on deploy:

    exports.durableObject({
  storage: "legacy-kv",
  // Object literal may only specify known properties,
  // and 'container' does not exist in type '{ storage: "legacy-kv" }'
  container: "my-container",
});

    This is an experimental feature: containers themselves are not yet configurable from cloudflare.config.ts, so the field is only useful once they are.

@cloudflare/vite-plugin@1.53.0

Minor Changes

  • #15026 6529f0c Thanks @petebacondarwin! - Allow containers to be attached to a Durable Object from its exports entry

    A container can now be linked to its Durable Object from the export side, using a new container field that names an entry in the containers array. As a result containers[].class_name is now optional — a container that is referenced this way only needs a name:

    {
  "name": "my-worker",
  "main": "worker.js",
  "compatibility_date": "2026-07-01",
  "containers": [
    { "name": "my-container", "image": "./Dockerfile", "max_instances": 1 }
  ],
  "exports": {
    "MyContainerDO": {
      "type": "durable-object",
      "storage": "sqlite",
      "container": "my-container"
    }
  }
}

    The existing containers[].class_name direction keeps working and either direction may be used, but the two must agree: a container that names its Durable Object cannot also be claimed by a different one.

    container is only valid on live durable-object exports (created and expecting-transfer) and requires storage: "sqlite". Wrangler now also reports an error when:

    • a container reference names a container that does not exist
    • two Durable Object exports claim the same container
    • a container and a Durable Object export disagree about which one they are linked to
    • a container ends up linked to no Durable Object at all
    • two containers share a name
    • a container's class_name names a Durable Object whose storage is legacy-kv
    • two containers are attached to the same Durable Object

    That last case was previously accepted but could never work: workerd attaches a single container per Durable Object namespace, and in local development every container for a class builds into the same image tag, so one silently overwrote the other. If you have two containers on one class_name, give each its own Durable Object class.

Patch Changes

  • #15238 3a4fc6b Thanks @jamesopstad! - Honor access.dev when running Workers with @cloudflare/vite-plugin, so ctx.access.getIdentity() returns the configured identity.

  • #15028 d4f441f Thanks @harshmathurx! - Handle Worker-side request body cancellation without surfacing stream controller errors in local dev.

  • #15185 1f79ace Thanks @jamesopstad! - Use a fixed default compatibility date rather than the current date

    When no compatibility date was set, Wrangler, C3 and the Vitest pool all defaulted to the current date. workerd only accepts a compatibility date up to 7 days beyond its own release, so whenever a workerd release was delayed the default could get ahead of the runtime that had been installed, and local development would fail to start.

    The default is now fixed at the release date of the workerd version that ships with each release, which leaves a week of headroom and updates as workerd is upgraded. @cloudflare/vite-plugin previously inlined the date at which it was built. It now shares the same default.

  • #15239 f431166 Thanks @jamesopstad! - Prevent date-enabled Node.js compatibility from adding conflicting globals to generated runtime types

    Runtime type generation now treats Node.js compatibility enabled by a compatibility date the same way as an explicit nodejs_compat flag. Node.js globals continue to come from @types/node instead of being generated as any declarations that override those types.

  • #15196 8fb2b87 Thanks @skepticfx! - Use the FedRAMP High managed container registry when Wrangler targets the FedRAMP High compliance region

    Container builds, pushes, deployments, image commands, and local development now select the corresponding production or staging FedRAMP registry and API from either compliance_region or CLOUDFLARE_COMPLIANCE_REGION.

  • Updated dependencies [bc5726b, 1277a72, ba54f0d, 6529f0c, b7422b0, 186339c, 4f922dc, 4d74b8d, 2e0c962, 1f79ace, 49f73de, 7cee278, 8777180, 265256a, 1f79ace, f431166, 8fb2b87, 75cf407]:

@cloudflare/vitest-pool-workers@0.22.0

Minor Changes

  • #13830 49d4e00 Thanks @penalosa! - Mocking requests with MSW in Worker tests now requires MSW >= 2.14

    @cloudflare/vitest-pool-workers previously shipped internal shims to make MSW work inside the workerd runtime. MSW 2.14 added that support natively, so those shims have been removed.

    If you mock requests with MSW in your Worker tests, make sure you're on MSW >= 2.14; older versions will no longer intercept requests. You can keep using setupServer() from msw/node, or adopt the official @msw/cloudflare integration via setupNetwork(). See the updated request-mocking example fixture for the recommended pattern.

Patch Changes

  • #15211 bc5726b Thanks @nithin42! - Honor access.dev when running Workers with @cloudflare/vitest-pool-workers, so ctx.access.getIdentity() returns the configured identity just as it does with wrangler dev.

  • #15156 3ddd3ce Thanks @dario-piotrowicz! - Fix module resolution for relative require() inside CJS deps when the project path contains spaces

    When a project lives under a directory with a space in its name, externalized CommonJS dependencies that use relative require() calls (e.g. require("./lib/impl.js")) would fail with "No such module" because workerd preserves URL encoding in the module name. Encoded module paths are now handled deterministically before CommonJS resolution without altering literal percent sequences.

  • #15150 2cf3143 Thanks @kkkhs! - Restore typed inject() keys in cloudflareTest() pool options

    inject() inside cloudflareTest() options again infers the value type from the keys you declare in your Vitest ProvidedContext, and reports misspelled keys. For keys that are only provided at runtime, pass an explicit type argument, e.g. inject<number>("myPort").

  • #15232 8777180 Thanks @vicb! - Bump capnp-es to 0.0.16.

  • #15185 1f79ace Thanks @jamesopstad! - Use a fixed default compatibility date rather than the current date

    When no compatibility date was set, Wrangler, C3 and the Vitest pool all defaulted to the current date. workerd only accepts a compatibility date up to 7 days beyond its own release, so whenever a workerd release was delayed the default could get ahead of the runtime that had been installed, and local development would fail to start.

    The default is now fixed at the release date of the workerd version that ships with each release, which leaves a week of headroom and updates as workerd is upgraded. @cloudflare/vite-plugin previously inlined the date at which it was built. It now shares the same default.

  • Updated dependencies [bc5726b, 1277a72, ba54f0d, 6529f0c, b7422b0, 186339c, 4f922dc, 4d74b8d, 2e0c962, 1f79ace, 49f73de, 7cee278, 8777180, 265256a, 1f79ace, f431166, 8fb2b87, 75cf407]:

wrangler@4.124.0

Minor Changes

  • #15026 6529f0c Thanks @petebacondarwin! - Allow containers to be attached to a Durable Object from its exports entry

    A container can now be linked to its Durable Object from the export side, using a new container field that names an entry in the containers array. As a result containers[].class_name is now optional — a container that is referenced this way only needs a name:

    {
  "name": "my-worker",
  "main": "worker.js",
  "compatibility_date": "2026-07-01",
  "containers": [
    { "name": "my-container", "image": "./Dockerfile", "max_instances": 1 }
  ],
  "exports": {
    "MyContainerDO": {
      "type": "durable-object",
      "storage": "sqlite",
      "container": "my-container"
    }
  }
}

    The existing containers[].class_name direction keeps working and either direction may be used, but the two must agree: a container that names its Durable Object cannot also be claimed by a different one.

    container is only valid on live durable-object exports (created and expecting-transfer) and requires storage: "sqlite". Wrangler now also reports an error when:

    • a container reference names a container that does not exist
    • two Durable Object exports claim the same container
    • a container and a Durable Object export disagree about which one they are linked to
    • a container ends up linked to no Durable Object at all
    • two containers share a name
    • a container's class_name names a Durable Object whose storage is legacy-kv
    • two containers are attached to the same Durable Object

    That last case was previously accepted but could never work: workerd attaches a single container per Durable Object namespace, and in local development every container for a class builds into the same image tag, so one silently overwrote the other. If you have two containers on one class_name, give each its own Durable Object class.

Patch Changes

  • #15211 bc5726b Thanks @nithin42! - Honor access.dev when running Workers with @cloudflare/vitest-pool-workers, so ctx.access.getIdentity() returns the configured identity just as it does with wrangler dev.

  • #14999 ba54f0d Thanks @mittalpk! - Fix .env loading on Windows leaking stale, differently-cased duplicate keys

    On Windows, wrangler loads .env values through a case-insensitive Proxy wrapper so lookups like env.PATH and env.Path resolve to the same value, and this object is assigned directly to process.env. When a key was set again under a different casing (e.g. a value in .env.local overriding one from .env with different casing), the previous casing was never removed from the underlying object. env.PATH/env.Path still returned the correct, latest value, but anything that enumerates process.env — Object.keys, for...in, JSON.stringify, object spread, or a spawned subprocess inheriting the environment — would see both the stale and current key.

    Duplicate entries no longer appear, so environment variables passed to subprocesses and any code that lists the environment now see only the latest value for each variable.

  • #15044 b7422b0 Thanks @stareezy-1! - Normalize structural CRLF line endings before sending D1 commands to the remote query API

    wrangler d1 migrations apply --remote and wrangler d1 execute --remote --command failed with incomplete input: SQLITE_ERROR when the SQL contained CRLF line endings inside a compound statement such as a CREATE TRIGGER ... BEGIN ... END; body. Structural line endings are now normalized to LF before the command is sent to the D1 query API, while CRLF inside quoted values and identifiers remains unchanged.

  • #15046 186339c Thanks @erwinzhang7! - Fixes D1 SQL statements not handling lowercase ends correctly

    wrangler d1 execute and wrangler d1 migrations apply split a SQL file into statements before running them. A BEGIN or CASE block closed with a lowercase end was not recognised as closed, so every statement after it was folded into that block instead of being run on its own. SQLite accepts either case, so a file like this applied only the trigger and silently skipped the table:

    CREATE TRIGGER IF NOT EXISTS update_trigger AFTER UPDATE ON items
begin
	DELETE FROM updates WHERE item_id=old.id;
end;
CREATE TABLE after_the_trigger (id TEXT PRIMARY KEY);

    Files written with an uppercase END were unaffected. Both cases now behave the same.

  • #15231 4f922dc Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

    The following dependency versions have been updated:

    Dependency From To
    @cloudflare/workers-types ^5.20260811.1 ^5.20260814.1
    workerd 1.20260811.1 1.20260814.1

  • #15248 4d74b8d Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

    The following dependency versions have been updated:

    Dependency From To
    @cloudflare/workers-types ^5.20260814.1 ^5.20260815.1
    workerd 1.20260814.1 1.20260815.1

  • #15185 1f79ace Thanks @jamesopstad! - Resolve --latest to the newest compatibility date supported by the installed runtime

    wrangler deploy --latest and wrangler versions upload --latest resolved the compatibility date to the current date, and wrangler pages download config did the same for projects configured to always use the latest compatibility date. Both write that date into a configuration file for subsequent commands to use, so a date that the installed workerd did not yet support left the project unable to run wrangler dev.

    These now resolve to the latest compatibility date supported by this version of Wrangler, which is the release date of the workerd it ships with.

  • #15151 49f73de Thanks @maximilliangrand! - Fix spurious Trailing comma jsonc(519) warnings for wrangler.jsonc in VS Code 1.131+

    Trailing commas in wrangler.jsonc files that reference Wrangler's JSON schema are no longer reported as errors by recent versions of VS Code. Wrangler always accepted these files; only the editor warning was wrong.

  • #14983 7cee278 Thanks @kdelay! - Respect CLOUDFLARE_ACCOUNT_ID in wrangler pages project list, create and delete

    These three commands could target a previously used account even when CLOUDFLARE_ACCOUNT_ID was set, failing with Authentication error [code: 10000] in setups with more than one account. They now use the account named by CLOUDFLARE_ACCOUNT_ID, matching the rest of wrangler pages. When the variable is unset, the previously used account is still selected, as before.

  • #15153 265256a Thanks @podonnell-dev! - Fix wrangler preview base-config commands showing an inherited script positional

  • #15185 1f79ace Thanks @jamesopstad! - Use a fixed default compatibility date rather than the current date

    When no compatibility date was set, Wrangler, C3 and the Vitest pool all defaulted to the current date. workerd only accepts a compatibility date up to 7 days beyond its own release, so whenever a workerd release was delayed the default could get ahead of the runtime that had been installed, and local development would fail to start.

    The default is now fixed at the release date of the workerd version that ships with each release, which leaves a week of headroom and updates as workerd is upgraded. @cloudflare/vite-plugin previously inlined the date at which it was built. It now shares the same default.

  • #15239 f431166 Thanks @jamesopstad! - Prevent date-enabled Node.js compatibility from adding conflicting globals to generated runtime types

    Runtime type generation now treats Node.js compatibility enabled by a compatibility date the same way as an explicit nodejs_compat flag. Node.js globals continue to come from @types/node instead of being generated as any declarations that override those types.

  • #15196 8fb2b87 Thanks @skepticfx! - Use the FedRAMP High managed container registry when Wrangler targets the FedRAMP High compliance region

    Container builds, pushes, deployments, image commands, and local development now select the corresponding production or staging FedRAMP registry and API from either compliance_region or CLOUDFLARE_COMPLIANCE_REGION.

  • #15082 75cf407 Thanks @penalosa! - Enable the new configuration format in the cf-wrangler dev delegate

    Projects started through cf dev now load cloudflare.config.ts and optional wrangler.config.ts, matching the configuration used by the delegate's build path.

  • Updated dependencies [1277a72, 4f922dc, 4d74b8d, 2e0c962, 8777180]:

@cloudflare/autoconfig@0.2.8

Patch Changes

  • Updated dependencies [fb6b51b, 1b73c87]:
    • @cloudflare/workers-utils@0.33.1
    • @cloudflare/cli-shared-helpers@0.1.24

@cloudflare/build-output-utils@0.1.2

Patch Changes

  • Updated dependencies [6529f0c]:
    • @cloudflare/config@0.6.0

@cloudflare/cli-shared-helpers@0.1.24

Patch Changes

  • Updated dependencies [fb6b51b, 1b73c87]:
    • @cloudflare/workers-utils@0.33.1

create-cloudflare@2.72.1

Patch Changes

  • #15217 1447950 Thanks @dependabot! - Update dependencies of "create-cloudflare"

    The following dependency versions have been updated:

    Dependency From To
    @angular/create 22.1.3 22.1.4

  • #15218 6d71eeb Thanks @dependabot! - Update dependencies of "create-cloudflare"

    The following dependency versions have been updated:

    Dependency From To
    create-solid 0.8.1 0.10.0

  • #15219 ee15a07 Thanks @dependabot! - Update dependencies of "create-cloudflare"

    The following dependency versions have been updated:

    Dependency From To
    create-next-app 16.3.0 16.3.1

  • #15220 1282749 Thanks @dependabot! - Update dependencies of "create-cloudflare"

    The following dependency versions have been updated:

    Dependency From To
    create-vinext-app 1.0.0-beta.1 1.0.0-beta.2

  • #15221 7af190a Thanks @dependabot! - Update dependencies of "create-cloudflare"

    The following dependency versions have been updated:

    Dependency From To
    create-analog 2.6.4 2.7.0

  • #15222 afe5788 Thanks @dependabot! - Update dependencies of "create-cloudflare"

    The following dependency versions have been updated:

    Dependency From To
    create-vike 0.0.673 0.0.675

  • #14953 05959fb Thanks @edmundhung! - Update the Hello World templates to use the latest version of @cloudflare/vitest-pool-workers.

  • #15185 1f79ace Thanks @jamesopstad! - Use a fixed default compatibility date rather than the current date

    When no compatibility date was set, Wrangler, C3 and the Vitest pool all defaulted to the current date. workerd only accepts a compatibility date up to 7 days beyond its own release, so whenever a workerd release was delayed the default could get ahead of the runtime that had been installed, and local development would fail to start.

    The default is now fixed at the release date of the workerd version that ships with each release, which leaves a week of headroom and updates as workerd is upgraded. @cloudflare/vite-plugin previously inlined the date at which it was built. It now shares the same default.

@cloudflare/deploy-helpers@0.7.1

Patch Changes

miniflare@5.20260815.0-alpha

Patch Changes

  • #15206 1277a72 Thanks @petebacondarwin! - Recover automatically from a partially downloaded Chrome install for the Browser Run binding

    If the Chrome download for a browser binding was interrupted — a cancelled dev session, a killed test run, a machine going to sleep — the next launch could fail indefinitely with Failed to launch the browser process!, usually alongside a message about being unable to load resources.pak. @puppeteer/browsers treats an install as present as soon as the executable exists, and the Chrome archives extract alphabetically, so the executable is written long before the resources it needs. Every subsequent launch then reused the half-written directory, and the only way out was deleting the Chrome cache by hand.

    Miniflare now detects this: an install that Chrome has never successfully started from is cleared and re-downloaded on a failed launch, rather than reused forever. Overlapping launches also share a single download instead of racing to populate the same directory.

  • #15231 4f922dc Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

    The following dependency versions have been updated:

    Dependency From To
    @cloudflare/workers-types ^5.20260811.1 ^5.20260814.1
    workerd 1.20260811.1 1.20260814.1

  • #15248 4d74b8d Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

    The following dependency versions have been updated:

    Dependency From To
    @cloudflare/workers-types ^5.20260814.1 ^5.20260815.1
    workerd 1.20260814.1 1.20260815.1

  • #15143 2e0c962 Thanks @teamleaderleo! - Prevent workerd from remaining running during Miniflare shutdown when browser or proxy cleanup is slow or fails.

  • #15232 8777180 Thanks @vicb! - Bump capnp-es to 0.0.16.

@cloudflare/pages-shared@0.13.170

Patch Changes

@cloudflare/workers-auth@0.6.4

Patch Changes

  • #15080 b6d00ed Thanks @teamleaderleo! - Use the current Cloudflare Access service-token credentials after environment variables change. Interactive Access cookie caching is unchanged.

  • Updated dependencies [fb6b51b, 1b73c87]:

    • @cloudflare/workers-utils@0.33.1

@cloudflare/workers-utils@0.33.1

Patch Changes

  • #15088 fb6b51b Thanks @Neal006! - Report malformed container SSH keys and a non-object containers.configuration as config errors instead of crashing

    Previously, a containers entry with a malformed authorized_keys or trusted_user_ca_keys entry (a missing or non-string public_key, or an entry that is not an object), or a containers.configuration set to null, made Wrangler exit with a stack trace and "If you think this is a bug, please open an issue" rather than pointing at the field.

    These configurations now produce an ordinary configuration error naming the offending field and array index, such as containers.authorized_keys[0].public_key must be a string. A public_key that is not an ED25519 key is also now reported with correct grammar.

  • #15010 1b73c87 Thanks @LeSingh1! - Report an invalid queues.consumers value as a configuration error instead of crashing

    Previously, setting queues.consumers to something other than an array (for example null or a string) could crash Wrangler or produce a flood of confusing extra errors. You now get a single clear message telling you the field must be an array.

@cloudflare/edge-preview-authenticated-proxy@0.3.3

Patch Changes

  • #15224 32782e4 Thanks @petebacondarwin! - Fix missing request and error metrics for the edge preview proxy

    The proxy stopped reporting its request and error counters, so dashboards and alerts based on them had no data. Metrics reporting now works again.

@cloudflare/remote-bindings@0.0.13

Patch Changes

@cloudflare/runtime-types@0.0.15

Patch Changes

@github-actions

github-actions Bot commented Aug 13, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

✅ All changesets look good

@pkg-pr-new

pkg-pr-new Bot commented Aug 13, 2026 •
edited
Loading

Copy link
Copy Markdown
@cloudflare/autoconfig

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

@cloudflare/build-output-utils

npm i https://pkg.pr.new/@cloudflare/build-output-utils@15175

@cloudflare/config

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

create-cloudflare

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

@cloudflare/deploy-helpers

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

@cloudflare/kv-asset-handler

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

miniflare

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

@cloudflare/pages-functions

npm i https://pkg.pr.new/@cloudflare/pages-functions@15175

@cloudflare/pages-shared

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

@cloudflare/unenv-preset

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

@cloudflare/vite-plugin

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

@cloudflare/vitest-pool-workers

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

@cloudflare/workers-auth

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

@cloudflare/workers-editor-shared

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

@cloudflare/workers-utils

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

wrangler

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

commit: bf82de9

devin-ai-integration[bot]
devin-ai-integration Bot reviewed Aug 13, 2026
View reviewed changes

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

Open in Devin Review

@workers-devprod
workers-devprod force-pushed the changeset-release/main branch 3 times, most recently from 3d029c1 to 7a86df6 Compare August 14, 2026 11:12
devin-ai-integration[bot]

This comment was marked as resolved.

Sign in to view

@workers-devprod
workers-devprod force-pushed the changeset-release/main branch 22 times, most recently from 9dd030f to d09ae49 Compare August 16, 2026 20:29
devin-ai-integration[bot]

This comment was marked as resolved.

Sign in to view

@workers-devprod
workers-devprod force-pushed the changeset-release/main branch 12 times, most recently from 2bff02e to 52b0990 Compare August 18, 2026 08:11
devin-ai-integration[bot]
devin-ai-integration Bot reviewed Aug 18, 2026
View reviewed changes

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 1 new potential issue.

View 3 additional findings in Devin Review.

Open in Devin Review

Comment thread .changeset/access-dev-vite-plugin.md
@edmundhung
edmundhung merged commit 8ee43f6 into main Aug 18, 2026
62 checks passed
@edmundhung
edmundhung deleted the changeset-release/main branch August 18, 2026 12:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@devin-ai-integration devin-ai-integration[bot] devin-ai-integration[bot] left review comments
@edmundhung edmundhung edmundhung approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@workers-devprod @edmundhung