Bump the workerd-and-workers-types group across 1 directory with 2 updates - #15123
Bump the workerd-and-workers-types group across 1 directory with 2 updates#15123dependabot[bot] wants to merge 9 commits into
Conversation
🦋 Changeset detectedLatest commit: f141cd8 The changes in this PR will be included in the next version bump. This PR includes changesets to release 13 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
|
✅ All changesets look good |
5f671b8 to
0839886
Compare
0839886 to
73b6f5e
Compare
@cloudflare/autoconfig
@cloudflare/build-output-utils
@cloudflare/config
create-cloudflare
@cloudflare/deploy-helpers
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-functions
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-auth
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
…dates Bumps the workerd-and-workers-types group with 2 updates in the / directory: [@cloudflare/workers-types](https://github.com/cloudflare/workerd) and [workerd](https://github.com/cloudflare/workerd). Updates `@cloudflare/workers-types` from 4.20260702.1 to 5.20260808.1 - [Release notes](https://github.com/cloudflare/workerd/releases) - [Changelog](https://github.com/cloudflare/workerd/blob/main/RELEASE.md) - [Commits](https://github.com/cloudflare/workerd/commits) Updates `workerd` from 1.20260804.1 to 1.20260808.1 - [Release notes](https://github.com/cloudflare/workerd/releases) - [Changelog](https://github.com/cloudflare/workerd/blob/main/RELEASE.md) - [Commits](cloudflare/workerd@v1.20260804.1...v1.20260808.1) --- updated-dependencies: - dependency-name: "@cloudflare/workers-types" dependency-version: 5.20260808.1 dependency-type: direct:production update-type: version-update:semver-major dependency-group: workerd-and-workers-types - dependency-name: workerd dependency-version: 1.20260808.1 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: workerd-and-workers-types ... Signed-off-by: dependabot[bot] <support@github.com>
The following dependency versions have been updated: | Dependency | From | To | | ------------------------- | ------------- | ------------- | | @cloudflare/workers-types | ^5.20260804.1 | ^5.20260808.1 | | workerd | 1.20260804.1 | 1.20260808.1 |
…eBatch()` The updated `@cloudflare/workers-types` now requires `delete()` on workflow instances and `deleteBatch()` on the workflow binding. These methods are now implemented in the local workflows simulator so that local dev and tests match the production API.
workerd now enables the `nodejs_compat` and `nodejs_compat_v2` flags by default for compatibility dates of 2026-08-04 or later, and rejects configs that also specify a flag its compatibility date already enables. `getNodeCompat()` only treated Node.js compatibility as enabled when a flag was listed explicitly, so it reported no Node.js compatibility for such dates. That made `@cloudflare/vitest-pool-workers` add a redundant `nodejs_compat_v2` to its runner worker, which workerd then rejected, and would also have skipped Wrangler's unenv polyfills and substituted `process.env` with an empty object in the Vite plugin. It now resolves both flags the way workerd does, and honours `no_nodejs_compat`. For the same reason `create-cloudflare` and `wrangler setup` no longer add `nodejs_compat` alongside the compatibility date they generate, and the repo's own configurations that paired the flag with such a date are updated.
`@cloudflare/workers-types` v5 declares the Node.js compatibility globals it did not cover before, including `process`. Like the other ambient globals it declares, `process` is a `const`, so TypeScript no longer treats it as a property of `typeof globalThis` and the fixture's `globalThis.process = process` fails to type check. That assignment is deliberate: it is there to check that assigning to `globalThis.process` does not produce a *build* time error. Keep it as it is and silence the type error instead, so the bundler coverage is preserved.
73b6f5e to
bea06a7
Compare
The `@cloudflare/workers-types` catalog entry is a caret range, so it had already resolved to 5.20260811.1 in the lockfile while `workerd` stayed pinned to 1.20260808.1. The two are released in lockstep, so line them up. The `nodejs_compat` and `nodejs_compat_v2` enable dates are unchanged in this release, and no other compatibility flag gained a 2026-08 enable date, so the Node.js compatibility work in this PR is unaffected.
…date Two things in C3 still keyed off the presence of the `nodejs_compat` flag, which is no longer written when the compatibility date already enables it: - `maybeInstallNodeTypes()` decided whether to install `@types/node` and add `node` to the project's `tsconfig.json` from the flag alone, so newly scaffolded TypeScript projects silently lost their Node.js typings. - The flag was only ever added, never removed, so one that a template or a framework's own scaffolder had already written survived next to a compatibility date that enables it, which workerd rejects. The flag resolution itself moves to `@cloudflare/workers-utils` as `resolveNodejsCompat()` so that C3 and Miniflare share one implementation rather than each having their own. Reported by Devin on #15123.
petebacondarwin
left a comment
There was a problem hiding this comment.
The majority of this PR was driven by Opus but I have read through all the code and claim it is acceptable. Another PR reviewer would be ideal though.
…mpat flag `wrangler types` decides whether to suggest installing `@types/node` from the resolved Node.js compatibility mode, which is now also enabled by a recent enough compatibility date. The message still claimed the suggestion was because "you have the `nodejs_compat` flag", which it now prints for Workers that do not set that flag at all.
| if (flags.length === 0) { | ||
| const { compatibility_flags: _removed, ...rest } = wranglerConfig; | ||
| return rest; | ||
| } |
There was a problem hiding this comment.
🔴 Setup can leave a project with a Node.js flag its date already enables, so the project fails to start
When no other compatibility flags remain, the whole flag list is dropped from the new configuration (const { compatibility_flags: _removed, ...rest } at packages/autoconfig/src/run.ts:277) instead of being written as an empty list, so an existing nodejs_compat written earlier by a framework's own scaffolder survives next to the freshly written date and the runtime rejects the project.
Impact: A project set up by wrangler setup can refuse to start or deploy with an error about the Node.js flag no longer needing to be specified.
Merge order in saveWranglerJsonc preserves the stale flag
runAutoConfig() always writes today's compatibility date (packages/autoconfig/src/run.ts:95), which is on or after NODEJS_COMPAT_DEFAULT_ON_DATE, so ensureNodejsCompatIsEnabled() strips every nodejs_* flag and, when nothing else is left, returns the config object without a compatibility_flags key.
saveWranglerJsonc() then merges { ...existingWranglerConfig, ...wranglerConfig } (packages/autoconfig/src/run.ts:306-316), where existingWranglerConfig is the wrangler.json(c) that the framework's configure() step may have just written. Because the key is absent from the new object, the pre-existing "compatibility_flags": ["nodejs_compat"] is kept, while compatibility_date is overwritten with today's date — exactly the combination workerd rejects.
Previously the function always emitted a compatibility_flags array, so the merge always overrode the existing value. The regression only manifests in the "nothing left to write" case.
Prompt for agents
In packages/autoconfig/src/run.ts, ensureNodejsCompatIsEnabled() now omits the compatibility_flags key entirely when the reconciled flag list is empty. saveWranglerJsonc() merges the generated config on top of any wrangler.json(c) that already exists in the project (typically written moments earlier by the framework's own scaffolder), using `{ ...existingWranglerConfig, ...wranglerConfig }`. Because the key is absent from the generated object, a stale `nodejs_compat` in the existing file survives, while compatibility_date is replaced with today's date — the exact combination workerd rejects. Consider making the removal explicit at write time, e.g. by having saveWranglerJsonc strip the redundant Node.js compatibility flags from the merged result (based on the final compatibility_date), rather than relying on the absence of the key to represent a deletion. Add a regression test that seeds an existing wrangler.jsonc containing `nodejs_compat` before runAutoConfig writes the config.
Was this helpful? React with 👍 or 👎 to provide feedback.
Bumps the
workerd-and-workers-typesgroup:workerd1.20260804.1 → 1.20260811.1 and@cloudflare/workers-types4.20260702.1 → 5.20260811.1.(The dependabot details below quote 1.20260808.1/5.20260808.1. The types entry is a caret range, so it had already resolved to 5.20260811.1 in the lockfile while
workerdstayed pinned to 1.20260808.1; the two are released in lockstep, so both are now on 1.20260811.1/5.20260811.1. Thenodejs_compatenable dates are unchanged in that release.)This bump is not self-contained, so it carries the changes needed to make the repo work against the new runtime.
nodejs_compatis now on by defaultworkerd now marks both
nodejs_compatandnodejs_compat_v2as enabled by default from compatibility date2026-08-04onwards, and rejects a config that specifies a flag its compatibility date already enables:getNodeCompat()in Miniflare only ever treated Node.js compatibility as enabled when a flag was listed explicitly, so for those dates it reported that there was no Node.js compatibility at all. Consequences:@cloudflare/vitest-pool-workersadded a redundantnodejs_compat_v2to its runner worker, which workerd then rejected. This is the visible failure — it defaults the compatibility date to today's date, so it broke as soon as the runtime was bumped, without anyone changing a config.process.envwith an empty object.getNodeCompat()now resolves both flags the way workerd does, and honoursno_nodejs_compat, which it previously ignored entirely. The date lives in one place, asNODEJS_COMPAT_DEFAULT_ON_DATEin@cloudflare/workers-utils.There were no tests for
getNodeCompat()before; there are now 17 covering the flag/date matrix.Generated and existing configs
For the same reason,
create-cloudflareandwrangler setupno longer addnodejs_compatnext to a compatibility date that already enables it — otherwise every newly scaffolded project fails to start. Six C3 templates and the repo's own configs that paired the flag with such a date are updated too.Two follow-ups in C3, both found by Devin on this PR: it removes the flag when a template or a framework's own scaffolder already wrote it next to such a date, and it no longer relies on that flag to decide whether a project needs
@types/node(which would otherwise have quietly cost every new TypeScript project its Node.js typings). The flag resolution now lives in@cloudflare/workers-utilsasresolveNodejsCompat(), shared with Miniflare instead of duplicated.Tooling deliberately does not strip a redundant flag from user config. The compatibility date is the opt-in, so workerd's error is the correct signal, and the changeset documents the one-line fix. Worth noting the blast radius is wider than local dev: the control plane runs the same validation, so an existing Worker with
nodejs_compatwill be rejected bywrangler deploythe first time it bumps its compatibility date past 2026-08-04.Known issues, tracked separately
Devin raised three findings against the other commits already on this branch. They are split out so this bump is not held up by them:
inject()in pool options no longer infers types or checks keys #15137 —inject()in vitest-pool-workers pool options no longer infers types or checks keysdeleteBatch()always reports success, so failures are invisible #15138 — localdeleteBatch()always reports success, so failures are invisibledelete()anddeleteBatch()have no test coverage #15139 — localdelete()/deleteBatch()have no test coverage@cloudflare/workers-typesv5The types major adds the Node.js compatibility globals it did not cover before, including
process. Like every other ambient global it declares,processis aconst, so TypeScript no longer treats it as a property oftypeof globalThis, andglobalThis.process = processin thepages-nodejs-v2-compatfixture stopped type checking. That assignment is there to check the assignment does not produce a build time error, so it is kept as-is and the type error is silenced, preserving the bundler coverage.nodejs_compatare stale as a result of the runtime change and are owned by it.Original dependabot description
Bumps the workerd-and-workers-types group with 2 updates in the / directory: @cloudflare/workers-types and workerd.
Updates
@cloudflare/workers-typesfrom 4.20260702.1 to 5.20260808.1Commits
Updates
workerdfrom 1.20260804.1 to 1.20260808.1Release notes
Sourced from workerd's releases.
Commits
a955a87Release 2026-08-08a861db3Merge pull request #6934 from cloudflare/harris/2026-08-07-reland-vuln-1875d701d3Merge pull request #6931 from cloudflare/jasnell/writer-kj-ptra5ce01fMerge pull request #6930 from cloudflare/kenton/enable-ctx-abort8d45594attempt to fix release (#6933)322d59bMake ctx.abort() (for stateless workers) non-experimental.adb9a5dDo not pass raw reference over Writer attachc317b59Use kj::Ptr<Writer> instead of Writer&e7b2192Fix issue where IoContext could be aborted while waiting for lock.5374389Merge pull request #6929 from cloudflare/maizatskyi/2026-08-07-upstreamDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions