chore(deps): update all non-major dependencies by khepri-bot[bot] · Pull Request #144 · gordon-code/github-tracker

khepri-bot · 2026-08-31T05:50:00Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
@cloudflare/vite-plugin (source)	`1.51.2` → `1.52.1`
@cloudflare/vitest-pool-workers (source)	`0.21.0` → `0.21.3`
@testing-library/user-event	`14.6.3` → `14.6.4`
daisyui (source)	`5.7.16` → `5.7.17`
pnpm (source)	`11.21.0` → `11.22.0`
wrangler (source)	`4.120.1` → `4.123.0`

Release Notes

cloudflare/workers-sdk (@cloudflare/vite-plugin)

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

#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.
Updated dependencies [d0c976c, d0c976c, 0b82b15, d0c976c, d0c976c, 90dd5e5, 3b02915]:
- miniflare@5.20260811.0-alpha
- wrangler@4.122.0

`v1.51.3`

Compare Source

Patch Changes

Updated dependencies [15cad03, 026e058, 731b33a, e1b5b4b, 5b1b930, 6e7d37d, d669088, 15cad03, c7aede7, 0aa8fa5]:
- wrangler@4.121.0
- miniflare@5.20260804.1-alpha

cloudflare/workers-sdk (@cloudflare/vitest-pool-workers)

`v0.21.3`

Compare Source

Patch Changes

Updated dependencies [b8fd112, f0f2054, 339509d]:
- miniflare@5.20260811.1-alpha
- wrangler@4.123.0

`v0.21.2`

Compare Source

Patch Changes

#15123 d0c976c Thanks @dependabot! - 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.
#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! - 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.
#15131 90dd5e5 Thanks @vicb! - Bump capnp-es to 0.0.15.

Also re-generate the types for the latest .capnp files
Updated dependencies [d0c976c, d0c976c, 0b82b15, d0c976c, d0c976c, 90dd5e5, 3b02915]:
- miniflare@5.20260811.0-alpha
- wrangler@4.122.0

`v0.21.1`

Compare Source

Patch Changes

#14882 ab9132d Thanks @petebacondarwin! - Report built-in modules that a Worker's compatibility settings don't provide as module errors, instead of crashing workerd

Previously, a Worker whose module graph statically reached a compatibility-gated built-in that wasn't enabled — for example import "node:child_process" without nodejs_compat — took down the runtime with *** Received signal #11: Segmentation fault before any test ran. Vitest reported only Worker exited unexpectedly, naming neither the module nor the file that imported it, which made the cause very hard to find. The import didn't even have to be called; being reachable from the entrypoint was enough.

The module fallback service answered these specifiers with a redirect to the modules root, but workerd already resolves node:/cloudflare:/workerd: specifiers there, so the redirect pointed back at the module workerd was in the middle of resolving and it recursed until the stack overflowed. Such a specifier only reaches the fallback service when workerd's own registry has already missed, so it's now reported as not found: workerd raises No such module "node:child_process", matching what wrangler dev does for the same Worker. The accompanying pool error names the module and points at compatibility flags rather than suggesting you bundle it, which can't help for a module built into the runtime.
Updated dependencies [15cad03, 026e058, 731b33a, e1b5b4b, 5b1b930, 6e7d37d, d669088, 15cad03, c7aede7, 0aa8fa5]:
- wrangler@4.121.0
- miniflare@5.20260804.1-alpha

testing-library/user-event (@testing-library/user-event)

`v14.6.4`

Compare Source

Bug Fixes

keyboard event repeat property (#1312) (d7e80e3)

saadeghi/daisyui (daisyui)

`v5.7.17`

Compare Source

Bug Fixes

checkbox/radio .btn color when checked (#4677) (53f81f3)

pnpm/pnpm (pnpm)

`v11.22.0`: pnpm 11.22

Compare Source

Minor Changes

Added pnpm cache path, which prints the directory pnpm uses for its metadata cache. CI setups can use it to cache that directory — including the lockfile verification log, which lets a job skip re-checking an unchanged lockfile against the configured supply-chain policies.
--config.config-dir no longer reaches the config through a project's pnpm-workspace.yaml, and neither do the --config. spellings of the other settings a project manifest may no longer contribute (--config.pnpm-home-dir, --config.workspace-dir, --config.global-pkg-dir, --config.root-project-manifest-dir). None of them was ever a supported way to set those directories: pnpm resolves them from the environment, and these flags took effect only because the project-manifest merge re-applied the command line afterwards. The dedicated flags, such as --dir and --global-dir, are unaffected #13629.
pnpm config set refuses to write a setting to a project's pnpm-workspace.yaml that pnpm does not read from there, rather than leaving a key in the file that does nothing. Those settings are configDir, pnpmHomeDir, stateDir and the others that name machine-level state. The command fails with ERR_PNPM_CONFIG_SET_NOT_A_PROJECT_SETTING, naming where the setting does belong when it belongs somewhere. pnpm config delete still clears one that a file already carries, in whichever spelling it uses #13629.
Added a new setting minimumReleaseAgeExcludePrune. When enabled, pnpm add, pnpm update, and pnpm remove prune the entries of minimumReleaseAgeExclude in pnpm-workspace.yaml that the freshly written lockfile no longer resolves: versions that are gone are dropped (an entry is removed once none of its versions remain), and entries for packages that are no longer in the lockfile are removed too. Name patterns (@scope/*) are always kept. The cleanup is skipped when the install's lockfile does not cover the whole workspace (sharedWorkspaceLockfile: false), since entries another project still needs would look stale.

Renamed cleanupUnusedCatalogs to catalogPrune, so that catalog pruning and release-age exclude pruning use one vocabulary. cleanupUnusedCatalogs continues to work; when both are set, catalogPrune wins.
A project's pnpm-workspace.yaml can no longer choose where pnpm keeps its credentials, its own installation, or the registry it downloads its next version from. One of those settings is configDir, which decided where pnpm login writes the granted token. bin, dir, globalBinDir, globalDir, npmrcAuthFile, pnpmHomeDir, stateDir, userconfig and workspaceDir are ignored there now too, and pnpm warns about the ones it finds. cacheDir and storeDir are unaffected #13629.
Resolving a Node.js runtime version (devEngines.runtime / runtime: specifiers) is now much faster: the per-version release metadata is cached in the pnpm cache directory after its signature is verified, and an exact stable version such as runtime:22.23.2 no longer downloads the Node.js release index. A pinned runtime whose metadata was fetched once resolves without any network access, which removes the noticeable delay on the first node invocation in a project pinning an already-downloaded runtime #13899.

Patch Changes

Fixed intermittent ERR_PNPM_ENOENT and ERR_PNPM_ENOTEMPTY errors while renaming _tmp_* directories during installation with nodeLinker: hoisted, in workspaces that also use patchedDependencies.
pnpm add no longer re-resolves the dependency graph when pnpm-lock.yaml already holds a version satisfying the request — promoting a transitive dependency to a direct one, or adding to a second workspace package what a first one already depends on, now only saves the dependency in package.json and records its importer entry. A satisfying locked version is necessary but not sufficient: the install still falls back to a full resolution for a dist tag, an alias, a workspace:/catalog:/git/tarball specifier, --save-peer, an overridden package, a catalogMode other than manual, and — under resolutionMode: time-based or lowest-direct, which resolve a direct dependency to the low end of its range — a range several locked versions satisfy.
Global installs now switch over atomically. The command shims in the global bin directory point at a stable per-package link rather than at the directory a particular install produced, so pnpm add -g and pnpm update -g activate a new version by moving that one link instead of rewriting every shim. A command can no longer be missing from PATH while an install is in progress, and a failed install leaves the previous version in place.
pnpm audit --fix and pnpm audit --fix update no longer add minimumReleaseAgeExclude entries for patched versions that were published before the minimumReleaseAge cutoff. The publish time of each minimum patched version is now checked against the registry metadata, and only versions young enough to be blocked by the age gate get an exclusion entry #11563.
pnpm add <pkg>@<version> and pnpm update <pkg>@<version> under a non-manual catalogMode now move the catalog entry's resolution to the requested version. Previously, when the catalog entry was a range that covered the requested version but resolved to a different one, the request was dropped silently: nothing was installed, nothing was written, and no error was raised.
A project that wasn't part of an install that moved a catalog entry now follows the entry the next time it is installed. It used to keep the version the entry resolved to before — a version the entry no longer allowed — and no later install corrected it, so one catalog entry ended up resolved to two versions.
pnpm add <pkg>@<version> and pnpm update <pkg>@<version> under catalogMode: strict no longer fail with ERR_PNPM_CATALOG_VERSION_MISMATCH when the catalog entry is a range that the wanted version satisfies. The dependency keeps using the catalog; only a version that really falls outside the catalog's range is rejected #13715.
A changed catalogs or pnpm.overrides block no longer has to be the only change for pnpm install to update the lockfile in place. Editing an override while also removing a dependency, or changing a catalog entry in the same commit as a range bump, is now absorbed in one pass instead of re-resolving the whole dependency graph #13799.

Fixed the lockfile an in-place override update wrote when the overridden package was also a catalog entry: the entry kept the version it had before the override moved the package. The same could happen in reverse, when a catalog entry moved a package an override pins. Both cases now re-resolve instead.
pnpm install now updates the lockfile in place even when several kinds of changes happened since the last install — for example a removed dependency together with a widened ignoredOptionalDependencies list, or a dependency edit alongside a patch or settings change. Previously any combination of changes forced a full re-resolution #13763.
pnpm deploy injects workspace dependencies again, so the deploy directory is self-contained instead of symlinking back into the source workspace #13754. Enabling injectWorkspacePackages with dedupeInjectedDeps disabled now also rewrites already-linked workspace dependencies to injected copies.
pnpm deploy --no-optional no longer writes a lockfile whose snapshots reference optional dependencies that the deploy excluded.
Removing the last dependency that references a catalog entry via the fast lockfile update no longer leaves the stale catalog entry in pnpm-lock.yaml.
A git dependency whose clone (or shallow fetch) fails now reports which package it belongs to, under the ERR_PNPM_GIT_FETCH_FAILED code, with credentials in the repository URL redacted. When the lockfile records an SSH remote, the error also explains that fetching it needs an SSH key for that host, and that a lockfile entry written before pnpm v11.21 can be re-recorded over HTTPS with pnpm update <package> #13743.
An integrity recorded on a git dependency's resolution (resolution: {type: git, repo, commit, integrity: sha512-…}) is no longer treated as a checksum. pnpm never verifies a git checkout against such a hash — the commit pins the content — so it is now dropped when the lockfile is rewritten, and pnpm sbom no longer republishes it as a CycloneDX/SPDX checksum. Lockfiles carrying one also load again instead of failing with ERR_PNPM_BROKEN_LOCKFILE #13042.

pnpm sbom now also publishes the checksum of a type: binary runtime archive, which pnpm does verify.
A git dependency whose git ls-remote fails now reports the ERR_PNPM_GIT_RESOLVE_FAILED code, naming the dependency instead of printing a bare git invocation, with credentials in the repository URL redacted. A specifier that does not ask for SSH resolves over HTTPS, because the URL recorded in the lockfile has to work on every machine that installs it, so the error explains how to substitute the transport on a machine that can only reach the host over SSH (git config --global url."git@<host>:".insteadOf "https://<host>/") #13743.

A missing git executable is reported as one, instead of surfacing the raw failure to start the process.

Credentials embedded in a git specifier are redacted from the "Could not resolve <ref> to a commit of <repo>" errors too.

Resolving a public repository makes one git ls-remote round-trip instead of two.
pnpm install after moving a dependency between dependencies, devDependencies, and optionalDependencies now updates the lockfile in place instead of re-resolving the whole dependency graph #13696.
syncInjectedDepsAfterScripts no longer fails with ERR_PNPM_UNSUPPORTED_INODE_TYPE when a workspace package contains an inode that is neither a file nor a directory, such as the FIFO 1Password's environments create for .env. Such an inode cannot be hardlinked into the injected copy, so it is skipped and the rest of the package still syncs #13550.

syncInjectedDepsAfterScripts also no longer fails with EEXIST when a workspace package replaced a file with a directory of the same name since the injected copy was last synced.
syncInjectedDepsAfterScripts no longer fails with ENOTDIR when a workspace package replaced a directory with a file of the same name and the injected copy still held that directory's contents.
syncInjectedDepsAfterScripts now removes the bin link of a bin the script dropped. Previously only new bins were linked, so a build step that stopped declaring one left its shim behind, pointing at a command that was no longer there.
syncInjectedDepsAfterScripts now identifies a file by its device as well as its inode number. An inode number is only unique within one filesystem, so on its own it could match an unrelated file on another device and leave that path stale in the injected copy.
pnpm store prune no longer deletes the lockfile verification log. The log records which lockfile passed which supply-chain policies, so it stays valid across a prune of the store; keeping it lets the next install skip re-verifying an unchanged lockfile.
Widening a dependency's range no longer leaves the project on an older version. The lockfile update now points the project at the highest version of that dependency already in the lockfile that satisfies the new range — matching what a full resolution records — instead of keeping the locked version whenever it happened to satisfy, which could leave a duplicate behind. A range change that only an already-locked version satisfies is now also handled without re-resolving #13778.
resolutionMode is no longer ignored when minimumReleaseAge is in effect. lowest-direct and time-based pick the lowest satisfying version of a direct dependency again; previously any active release-age cutoff — including the built-in default — silently forced the highest, so resolutionMode only worked when minimumReleaseAge: 0 was set explicitly #13752.
Adding a package to a workspace no longer forces a full re-resolution when every dependency it declares is already locked for a sibling. The lockfile update writes the new project's importer entry from the versions the lockfile already holds; a dependency no locked version satisfies still reaches the resolver #13696.
pnpm config delete <key> no longer fails with ENOENT when the config file it would edit does not exist. Clearing a setting that was never set is a no-op #13651.
Changing a pnpm.overrides entry to a version range now updates the lockfile in place when a version the lockfile already holds satisfies the range, instead of re-resolving the whole dependency graph. Only exact versions were handled before #13696.
Changing a parent-scoped pnpm.overrides entry ("parent>child": "2.0.0") now updates the lockfile in place instead of re-resolving the whole dependency graph. Only the named parent's dependency moves; every other package keeps the version it had #13795.
Removing a dependency, or moving one to another already-locked version, no longer re-resolves the whole dependency graph just because some package resolves a peer with the same name. The lockfile update now compares the peer suffixes against the exact name@version the removal severed, so a suffix that names a different — still present — version of that dependency is left alone #13781.
Projects with a pnpmfile now use the fast lockfile update paths: an unchanged pnpmfile (proven by the recorded pnpmfileChecksum) no longer forces a full re-resolution for removals, dependency group moves, compatible range changes, and the other in-place lockfile rewrites #13696.
A lockfile entry whose resolution is unchanged no longer loses its recorded deprecated marker when a registry serves the package's metadata inconsistently — re-resolving to the same version keeps the deprecation instead of silently dropping the line #13846.
pnpm prune is now recursive by default inside a workspace, just like pnpm install. This fixes pnpm prune --prod in a workspace root emptying the node_modules directories of the other workspace projects, dropping the links to the workspace packages they depend on in production #13718.
A setting written in kebab-case in the global config.yaml is now reported instead of being silently ignored #13650.
pnpm remove no longer re-resolves the dependency graph. The removed dependency's entries are dropped from pnpm-lock.yaml and anything they made unreachable is pruned, without registry access. The install still falls back to a full resolution when a surviving package resolves a peer dependency through the removed one.
Removing a package from a workspace no longer forces a full re-resolution. The lockfile update drops the departed project's importer entry and prunes whatever only it depended on. A project that is still linked from a surviving project continues to be reported as an error #13696.
An install sharing a global virtual store no longer removes an incomplete package directory that another importer is still writing, which could fail with failed to remove existing directory ... prior to swap: Directory not empty. Such a directory is now repaired in place, and a package file left damaged by an interrupted install is restored instead of being kept.
pnpm sbom no longer emits components for optional platform-specific dependencies that cannot be installed on the current platform (for example, the native @rolldown/binding-* variants for other operating systems). Such packages are present in the lockfile but are never downloaded, so their license (and other metadata) could not be resolved and they appeared in the SBOM without one. pnpm sbom --lockfile-only still describes the whole lockfile graph, which is platform-independent by design.
An ssh:// git dependency pointing at a bracketed IPv6 host, such as ssh://[::1]/repo.git, is resolved now. Its colons were read as an SCP-style path separator, which turned the address into [:/1] and left the specifier unresolvable. Applies to both the TypeScript CLI and pacquet.

In the TypeScript CLI, an ssh:// git dependency written without user info — ssh://git.example.com/team/repo.git, git+ssh://git.example.com:2222/team/repo.git — no longer fails with TypeError: Cannot read properties of undefined (reading 'includes'). Only the user@host form worked before.
packageExtensions is now validated when the configuration is read, so a malformed entry (for instance a dependency range set to null) fails with an actionable error instead of crashing later during peer dependency resolution #13756.
Projects using resolutionMode: time-based now benefit from the fast lockfile update paths. A removal, a dependency group move, or a compatible range change no longer forces a full re-resolution just because the lockfile carries a time field #13696.
An install that drops the last dependent of a patched package no longer updates the lockfile in place and succeeds silently. Removing a dependency, widening ignoredOptionalDependencies, or adding a removal override could each prune the package while the patch stayed configured; such an install now falls back to a full resolution, which reports the unused patch with ERR_PNPM_UNUSED_PATCH. Under allowUnusedPatches, where the lockfile update is kept, the same install now warns that the patch went unused instead of saying nothing #13827.

Platinum Sponsors

Gold Sponsors

cloudflare/workers-sdk (wrangler)

`v4.123.0`

Compare Source

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

Updated dependencies [b8fd112]:
- miniflare@5.20260811.1-alpha

`v4.122.0`

Compare Source

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]:
- miniflare@5.20260811.0-alpha

`v4.121.0`

Compare Source

Minor Changes

#15079 15cad03 Thanks @podonnell-dev! - Add Preview base config secret commands

Wrangler now manages Worker Preview base config secrets with wrangler preview base-config secret put, delete, list, and bulk. These commands update the Worker's previews_base_config.env, keeping shared defaults scoped to all of that Worker's Previews. wrangler preview base-config secret list reads from the Worker's Preview base config and prints secret names with values masked. wrangler preview base-config secret bulk deletes a secret when its value is null, matching wrangler secret bulk.

#15000 731b33a Thanks @edmundhung! - Allow Wrangler projects to build a Worker once and reuse it in createTestHarness()

Build the Worker once:

wrangler deploy --dry-run --outdir ./worker-output

Then reuse the emitted Worker during test harness startup and reset:

const server = createTestHarness({
  workers: [
    {
      configPath: "./wrangler.jsonc",
      prebuiltWorkerDir: "./worker-output",
    },
  ],
});

#14737 e1b5b4b Thanks @ttoino! - Add email.sending as an event subscription source for queues

wrangler queues subscription create now accepts --source email.sending alongside two new flags, --zone-id and --domain, which identify the zone and the sending domain (zone apex or a verified subdomain) to subscribe to. Both flags are required for this source. The subscription's resource is displayed as the sending domain in wrangler queues subscription get.
#15073 d669088 Thanks @FlorentCollin! - Add US jurisdiction support to wrangler d1 create

You can now create a D1 database in the US jurisdiction with wrangler d1 create <name> --jurisdiction us. The new jurisdiction is also listed in the command's help output.
#15079 15cad03 Thanks @podonnell-dev! - Use Preview deployment PATCH APIs for Preview secret commands

Wrangler now updates Worker Preview secrets by patching the named Preview's latest deployment instead of patching the Worker's Previews settings. This keeps secret changes scoped to one Preview, avoids affecting production or other Previews, and creates a new Preview d

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (in timezone America/New_York)

Branch creation
- Between 12:00 AM and 08:59 AM, only on Monday (* 0-8 * * 1)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

chore(deps): update all non-major dependencies

5460e35

khepri-bot Bot requested a review from a team August 31, 2026 05:50

khepri-bot Bot added the renovate label Aug 31, 2026

Navigation Menu

Uh oh!

chore(deps): update all non-major dependencies - #144

chore(deps): update all non-major dependencies#144
khepri-bot[bot] wants to merge 1 commit into
mainfrom
renovate/all-non-major-dependencies

khepri-bot Bot commented Aug 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Dependency	From	To
@cloudflare/workers-types	^5.20260804.1	^5.20260811.1
workerd	1.20260804.1	1.20260811.1

Uh oh!

Conversation

khepri-bot Bot commented Aug 31, 2026

Release Notes

Patch Changes

Minor Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Bug Fixes

Bug Fixes

v11.22.0: pnpm 11.22

Minor Changes

Patch Changes

Platinum Sponsors

Gold Sponsors

Minor Changes

Patch Changes

Minor Changes

Patch Changes

Minor Changes

Configuration

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

`v11.22.0`: pnpm 11.22