Bump the workerd-and-workers-types group across 1 directory with 2 updates (#15123)

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Wrangler automated PR updater <wrangler@cloudflare.com>
Co-authored-by: Dario Piotrowicz <dario@cloudflare.com>
Co-authored-by: Pete Bacon Darwin <pbacondarwin@cloudflare.com>

Author: 4 people

.changeset/add-workflow-delete-apis.md

@@ -0,0 +1,7 @@
+---
+"miniflare": minor
+---
+
+Add local support for `WorkflowInstance.delete()` and `Workflow.deleteBatch()`
+
+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.

.changeset/dependabot-update-15123.md

@@ -0,0 +1,13 @@
+---
+"miniflare": patch
+"wrangler": patch
+---
+
+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  |

.changeset/fix-vitest-provided-context-types.md

@@ -0,0 +1,7 @@
+---
+"@cloudflare/vitest-pool-workers": patch
+---
+
+Widen `WorkerPoolOptionsContext.inject` type to avoid `ProvidedContext` mismatch
+
+Previously, calling `inject()` inside `cloudflareTest()` pool options could fail with a type error when your project's `ProvidedContext` augmentation wasn't visible to the pool plugin. The `inject` parameter now accepts any string key and is generic (`inject<T>(key)`), defaulting to `unknown` when no type argument is provided. This lets you opt in to concrete types (e.g. `inject<number>("port")`) while avoiding the cross-copy `ProvidedContext` mismatch that occurred when pnpm resolved separate virtual-store instances of vitest.

.changeset/no-redundant-nodejs-compat-in-generated-config.md

@@ -0,0 +1,13 @@
+---
+"@cloudflare/autoconfig": patch
+"create-cloudflare": patch
+"wrangler": patch
+---
+
+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.

.changeset/nodejs-compat-default-on-date.md

@@ -0,0 +1,36 @@
+---
+"@cloudflare/vitest-pool-workers": patch
+"@cloudflare/vite-plugin": minor
+"miniflare": minor
+"wrangler": minor
+---
+
+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.
+
+#### If you hit "does not need to be specified anymore"
+
+workerd rejects a compatibility flag that its compatibility date already enables, so a Worker that sets both a compatibility date of `2026-08-04` or later **and** `nodejs_compat` now fails to start or deploy with:
+
+```
+The compatibility flag nodejs_compat became the default as of 2026-08-04 so does not need to be specified anymore.
+```
+
+This is expected: bumping a compatibility date is how you opt in to behaviour changes. To fix it, remove the flag — Node.js compatibility remains enabled via the compatibility date:
+
+```jsonc
+// wrangler.json
+{
+	"compatibility_date": "2026-08-04",
+	// "compatibility_flags": ["nodejs_compat"] <-- remove this
+}
+```
+
+Note that if you do not set a `compatibility_date` at all, Wrangler, the Vite plugin and the Vitest pool infer today's date on your behalf, so you can hit this without having changed your own configuration. Either remove the flag as above, or set an explicit `compatibility_date` earlier than `2026-08-04`.
+
+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.

.changeset/workers-utils-nodejs-compat-default-on-date.md

@@ -0,0 +1,7 @@
+---
+"@cloudflare/workers-utils": minor
+---
+
+Add `NODEJS_COMPAT_DEFAULT_ON_DATE`, `NODEJS_COMPAT_V2_SWITCH_OVER_DATE`, `isNodejsCompatDefaultOn()` and `resolveNodejsCompat()`
+
+These expose the compatibility dates on which workerd started enabling `nodejs_compat` by default and on which `nodejs_compat` started implying `nodejs_compat_v2`, along with the resolution of both flags from a compatibility date and a set of compatibility flags, so that the tools which generate or interpret Wrangler configurations do not each reimplement it.

fixtures/pages-nodejs-v2-compat/apps/workerjs-directory/_worker.js/index.js

@@ -1,6 +1,8 @@
 process.env.foo = "bar";
 
 // Check that we don't get a build time error when assigning to globalThis.process.
+// @ts-expect-error `@cloudflare/workers-types` declares `process` as a `const`, so
+// TypeScript does not treat it as a property of `globalThis`, but this is valid at runtime.
 globalThis.process = process;
 
 export default {

fixtures/pages-nodejs-v2-compat/apps/workerjs-file/_worker.js

@@ -1,6 +1,8 @@
 process.env.foo = "bar";
 
 // Check that we don't get a build time error when assigning to globalThis.process.
+// @ts-expect-error `@cloudflare/workers-types` declares `process` as a `const`, so
+// TypeScript does not treat it as a property of `globalThis`, but this is valid at runtime.
 globalThis.process = process;
 
 export default {

fixtures/pages-nodejs-v2-compat/functions/[[path]].ts

@@ -1,6 +1,8 @@
 process.env.foo = "bar";
 
 // Check that we don't get a build time error when assigning to globalThis.process.
+// @ts-expect-error `@cloudflare/workers-types` declares `process` as a `const`, so
+// TypeScript does not treat it as a property of `globalThis`, but this is valid at runtime.
 globalThis.process = process;
 
 export const onRequest = () => {

fixtures/vitest-pool-workers-examples/hyperdrive/env.d.ts

@@ -1,7 +1,7 @@
+import "vitest";
+
 declare module "vitest" {
 	interface ProvidedContext {
 		echoServerPort: number;
 	}
 }
-
-export {};