chore(deps): bump sharp, @cloudflare/vitest-pool-workers and wrangler

[dependabot]

Bumps sharp to 0.35.2 and updates ancestor dependencies sharp, @cloudflare/vitest-pool-workers and wrangler. These dependencies need to be updated together.

Updates sharp from 0.34.5 to 0.35.2

Release notes

Sourced from sharp's releases.

v0.35.2

• TypeScript: Add mediaType to metadata response. #4492

• Improve WebAssembly fallback detection. #4513

• Improve code bundler support with stub binaries. #4543

• Verify GIF effort option is an integer. #4544 @​metsw24-max

• Verify recomb matrix entries are numbers. #4545 @​metsw24-max

• TypeScript: Replace namespace with named exports for ESM. #4546

• Bound dilate and erode width to avoid mask-size overflow. #4548 @​metsw24-max

• Verify convolve kernel values are numbers. #4549 @​metsw24-max

v0.35.2-rc.2

• TypeScript: Add mediaType to metadata response. #4492

• Improve WebAssembly fallback detection. #4513

• Improve code bundler support with stub binaries. #4543

• Verify GIF effort option is an integer. #4544 @​metsw24-max

• Verify recomb matrix entries are numbers. #4545 @​metsw24-max

• TypeScript: Replace namespace with named exports for ESM. #4546

... (truncated)

Commits

• c9622a3 Release v0.35.2
• cd4568f Upgrade to sharp-libvips v1.3.1
• 78390cf Tests: Add font file to prevent font discovery flakiness (#4550)
• 61210b4 Verify convolve kernel values are numbers (#4549)
• 1cb27dc Prerelease v0.35.2-rc.2
• c7606c3 Upgrade to sharp-libvips v1.3.1-rc.0
• 29d1e9e Prerelease v0.35.2-rc.1
• bbba0a1 Improve code bundler support with stub binaries
• ab52866 Bound dilate and erode width to avoid mask-size overflow (#4548)
• 0f594dd Prerelease v0.35.2-rc.0
• Additional commits viewable in compare view

Updates @cloudflare/vitest-pool-workers from 0.16.3 to 0.21.3

Release notes

Sourced from @​cloudflare/vitest-pool-workers's releases.

@​cloudflare/vitest-pool-workers@​0.21.3

Patch Changes

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

@​cloudflare/vitest-pool-workers@​0.21.2

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

@​cloudflare/vitest-pool-workers@​0.21.1

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](https://github.com/cloudflare/workers-sdk/tree/HEAD/packages/vitest-pool-workers/issues/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

... (truncated)

Changelog

Sourced from @​cloudflare/vitest-pool-workers's changelog.

0.21.3

Patch Changes

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

0.21.2

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

0.21.1

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](https://github.com/cloudflare/workers-sdk/tree/HEAD/packages/vitest-pool-workers/issues/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.

... (truncated)

Commits

• c576a82 Version Packages (#15154)
• e5d56e9 Version Packages (#15145)
• d0c976c Bump the workerd-and-workers-types group across 1 directory with 2 updates (#...
• 90dd5e5 chore: bump capnp-es to 0.0.15 (#15131)
• 15fc568 Version Packages (#15118)
• ab9132d [vitest-pool-workers] Report unavailable built-ins as module errors instead o...
• d2f377e Version Packages (#15111)
• 2194f88 new config miniflare attempt 3 (#14994)
• b0aea76 Version Packages (#15036)
• 2938c01 Version Packages (#15021)
• Additional commits viewable in compare view

Updates wrangler from 4.90.0 to 4.123.0

Release notes

Sourced from wrangler's releases.

wrangler@4.123.0

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

wrangler@4.122.0

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.

... (truncated)

Commits

• c576a82 Version Packages (#15154)
• 339509d Add automatic update prompts for out-of-date Cloudflare agent skills (#14872)
• b8fd112 feat: implement local dev for ctx.access (#15113)
• f0f2054 Replace ignore-defaults with ignore-base-config CLI arg for Previews (#15152)
• e5d56e9 Version Packages (#15145)
• 3b02915 [wrangler] Avoid stale remote binding sessions (#15142)
• d0c976c Bump the workerd-and-workers-types group across 1 directory with 2 updates (#...
• 15fc568 Version Packages (#15118)
• 5b1b930 Fetch script metadata directly instead of listing all scripts (#15132)
• 0aa8fa5 Support DO_NOT_TRACK=1 (#14924)
• Additional commits viewable in compare view

Dependabot 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 rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.