chore(deps): update dependency @cloudflare/vitest-pool-workers to ^0.22.0

[renovate]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
@cloudflare/vitest-pool-workers (source)	^0.8.19 → ^0.22.0

---

Release Notes

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

v0.22.0

Compare Source

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
  • miniflare@5.20260815.0-alpha

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

v0.21.0

Compare Source

Minor Changes

• #​14994 2194f88 Thanks @​emily-shen! - Update the Workers Vitest pool for Miniflare's config-based options

  The Workers Vitest pool now converts the Miniflare options it creates for test sessions to Miniflare's config-based workers shape.

  For the most part, users should not expect to notice any changes.

  However, while miniflare.modulesRules is preserved for common text and WASM fixture imports, it is not a full replacement for Miniflare's old modules: true module graph collection and you may notice some differences in behaviour.

Patch Changes

• Updated dependencies [6dbd192, 2194f88, 2194f88, 2194f88, 2194f88, 2194f88, 2194f88, 2194f88]:
  • miniflare@5.20260804.0-alpha
  • wrangler@​4.120.1

v0.20.3

Compare Source

Patch Changes

• #​15013 8cf78c8 Thanks @​dario-piotrowicz! - Update undici from 7.28.0 to 7.29.0

• Updated dependencies [35c87e9, b4f0c97, 8cf78c8, a60ff4d, 99eb50c, 35c87e9]:

  • wrangler@​4.120.0
  • miniflare@5.20260801.1-alpha

v0.20.2

Compare Source

Patch Changes

• Updated dependencies [20470fa, 9c74538, 266172b, a88d169, a88d169, daf65f2, a9e5abb]:
  • wrangler@​4.119.0
  • miniflare@5.20260801.0-alpha

v0.20.1

Compare Source

Patch Changes

• Updated dependencies [cc63aae, f92d1fc, a249591, f92d1fc, f92d1fc, cec9d88, e0bbf55]:
  • wrangler@​4.118.0

v0.20.0

Compare Source

Minor Changes

• #​14586 5a56dda Thanks @​emily-shen! - Breaking change: Remove several options from the miniflare override options

  The following options have been removed from the miniflare override options, as they were not intended to be exposed, were not functional, or have been superseded by other options:

  • wrappedBindings
  • cacheWarnUsage
  • fetchMock: you should use outboundService instead
  • containerEngine: containers were not supported in vitest-pool-workers. Consider using createTestHarness() instead if you want to test against actual containers.

  Additionally, cache has been deprecated and renamed to cacheAPI, but cache remains functional.

Patch Changes

• #​14586 5a56dda Thanks @​emily-shen! - Preserve the deprecated Miniflare cache option

  Vitest configurations using cache continue to work after the internal Miniflare v5 upgrade. The option is translated to cacheAPI; new configurations should use cacheAPI directly.

• #​14586 5a56dda Thanks @​emily-shen! - Stop enabling Miniflare's removed unsafeStickyBlobs option

  The pool no longer sets the unsafeStickyBlobs Miniflare option, which has been removed. This option was only needed for the Durable Object isolated storage feature that was dropped in 0.13.0, so there is no change in behaviour.

• Updated dependencies [5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda, 5a56dda]:

  • miniflare@5.20260730.0-alpha
  • wrangler@​4.117.0

v0.19.1

Compare Source

Patch Changes

• Updated dependencies [01d7020, beec0fb, 48f0c6c, 8049ca4, d7f38c3, 1394867, cc54478, 5c25cfe, b21eac2, bb09f1b, 1f61001, 01d7020, e31ab0f]:
  • miniflare@​4.20260730.0
  • wrangler@​4.116.0

v0.19.0

Compare Source

Minor Changes

• #​14879 e6480e3 Thanks @​dmmulroy! - Add a verbose option to cloudflareTest() and cloudflarePool() configuration

  Set verbose: false to suppress verbose workerd runtime logs, such as caught Durable Object RPC errors. The option defaults to true to preserve existing output.

Patch Changes

• #​14821 edc203e Thanks @​mishushakov! - Ignore workerd's disconnected: peer disconnected without gracefully ending TLS session exception logs

  When tests make real fetch() calls to external TLS endpoints, servers and load balancers routinely close idle keepalive connections without sending a TLS close_notify. No request fails — the connection is idle — but workerd logs a kj/compat/tls.c++ exception with a full stack trace each time, flooding otherwise green test runs. This is the TLS sibling of the disconnected: ... messages already in the ignore list, so filter it the same way.

• Updated dependencies [773ead4, 773ead4, 09b8a44, 4dfb96e, 1035f74, e426cb9, 3a22ae5, 465c0fb, 465c0fb, e8b3a9d, 552bcfc, b737676, 6e0bf6e]:

  • wrangler@​4.115.0
  • miniflare@​4.20260722.1

v0.18.8

Compare Source

Patch Changes

• #​14793 7b3fea6 Thanks @​trafgals! - Prevent worker disposal errors from failing otherwise successful test runs

  Errors raised while disposing test Workers are now logged for diagnostics rather than overriding the test result. Set NODE_DEBUG=vitest-pool-workers to view these errors.

• Updated dependencies [246ce92, c38a2c3, 8416b33, c079ba3, 4683ff8, 95b026e, 02232f3, c4bacec, f8a8c2c, 3203b5d]:

  • wrangler@​4.114.0
  • miniflare@​4.20260722.0

v0.18.7

Compare Source

Patch Changes

• #​14713 de34449 Thanks @​allocsys! - Fix a non-ASCII path failure during the Miniflare WebSocket handshake: the MF-Vitest-Worker-Data header embedded the raw process.cwd() value, which threw a Latin-1/ASCII header encoding error when the workspace path contained non-ASCII characters (e.g. CJK characters) on Windows. The value is now percent-encoded on write and decoded on read, matching the fix applied to the module fallback redirect response.

• #​14713 de34449 Thanks @​allocsys! - Fix a runtime start-up failure ("No such module "cloudflare:test-internal"") when the project workspace path contains non-ASCII characters (e.g. CJK characters) on Windows. The module fallback service's redirect response set the target file path directly as an HTTP Location header value, but headers are restricted to the Latin-1/ASCII byte range, so any non-ASCII byte in the path caused header construction to throw. Such paths are now percent-encoded (and tagged with a sentinel prefix) before being used as a header value, and decoded again only for the values we encoded, so the round-trip is unambiguous and a workspace path containing a literal % is left untouched instead of being mis-decoded.

• #​14739 5eac99e Thanks @​Ankcorn! - Support testing Streaming Tail Workers in Vitest Pool Workers.

• #​14763 538e867 Thanks @​gianghungtien! - Treat webSocketMessage(), webSocketClose() and webSocketError() as optional Durable Object handlers

  The pool wraps each Durable Object class and installs a prototype method for every default handler before user code is loaded, so workerd always sees a handler and always dispatches. When the wrapped class didn't actually define one, the wrapper threw <ClassName> exported by <path> does not define a `webSocketClose()` method, even though deployed Workers silently ignore these events for classes that omit them. A hibernatable Durable Object defining only webSocketMessage() would log an uncaught TypeError on every close.

  These three handlers now no-op when absent, matching deployed behaviour. alarm() is unchanged and still reports a missing handler, since workerd rejects setAlarm() up front on a class without one.

• Updated dependencies [42af66d, a0a091b, f03b108, deae171, 0df3d43, d83a476, 4e92e32, d1d6945, 4815711, a0c8bb1, a50f73a, 2b390d7, c82d96b, 34430b3, f75ae5d]:

  • miniflare@​4.20260721.0
  • wrangler@​4.113.0

v0.18.6

Compare Source

Patch Changes

• #​14678 4e62bba Thanks @​apeacock1991! - Fix test runs hanging after a Durable Object logs and rejects blockConcurrencyWhile()

  Console messages emitted from another Durable Object are now buffered until execution returns to the test runner, avoiding I/O that cannot complete after the object's input gate breaks.

• Updated dependencies [34e696d, d39ae01, 3de70df, c79504f, 9f04a7e, 9f04a7e, cb30df3, cb6c3f9, c7dbe1a, 3f3afbb, e6fbc4e, 4e1a7a7, 9f04a7e]:

  • miniflare@​4.20260714.0
  • wrangler@​4.112.0

v0.18.5

Compare Source

Patch Changes

• Updated dependencies [7692a61, ed33326, 018574b, eb99ab1, cdf3148, 7692a61, 7692a61, 3015320, 899c297, 9da77ac, 317ce1f]:
  • miniflare@​4.20260710.0
  • wrangler@​4.111.0

v0.18.4

Compare Source

Patch Changes

• #​14535 1b965c5 Thanks @​Naapperas! - Support dynamic retry delays for Workflow steps in local dev

  A step's retries.delay can now be a function that computes the delay per failed attempt, in addition to a static duration. The function receives { ctx, error } and returns a delay (a number of milliseconds or a duration string like "30 seconds"), and its result is fed into the configured backoff.

  await step.do(
    "call flaky API",
    {
      retries: {
        limit: 5,
        backoff: "constant",
        delay: ({ ctx }) => ctx.attempt * 1000,
      },
    },
    async () => {
      /* ... */
    }
  );

  The function is invoked once per failed attempt with a 5 second timeout. If it throws, times out, or returns an invalid value, the step fails without further retries.

• Updated dependencies [0283a1f, 7b28392, 1b965c5]:

  • wrangler@​4.110.0
  • miniflare@​4.20260708.1

v0.18.3

Compare Source

Patch Changes

• #​14489 e3f0cd6 Thanks @​edmundhung! - Add listDurableObjectIds() to Miniflare

  Miniflare now exposes listDurableObjectIds() for listing persisted Durable Object instance IDs by binding name. The Vitest pool now uses this shared Miniflare API internally instead of duplicating Miniflare's storage listing logic.

• Updated dependencies [e3f0cd6, 8511ddf, 9f74a5f, e3f0cd6, c782e2a, 2fedb1f, 17d2fc1]:

  • miniflare@​4.20260708.0
  • wrangler@​4.109.0

v0.18.2

Compare Source

Patch Changes

• Updated dependencies [54f74b8, 0852346, 54f74b8]:
  • wrangler@​4.108.0
  • miniflare@​4.20260706.0

v0.18.1

Compare Source

Patch Changes

• #​14409 16fbf81 Thanks @​matingathani! - reset() from cloudflare:test now resets ratelimit binding state between tests. Previously, RATE_LIMITERS bindings retained their in-memory bucket counts across test boundaries, causing later tests in the same file to see stale rate-limit exhaustion state.

• Updated dependencies [e7e5780, d88555e, 5fd8bee, 5d9990e, bf49a41, 1ac96a1, f416dd9, 1ca8d8f, 16fbf81, b973ed3]:

  • miniflare@​4.20260702.0
  • wrangler@​4.107.1

v0.18.0

Compare Source

Minor Changes

• #​14382 fd92d56 Thanks @​petebacondarwin! - Add support for declarative Durable Object exports

  wrangler deploy now accepts an exports map in wrangler.json as a declarative alternative to the legacy migrations array.

  Each entry in exports is keyed by Durable Object class name. type carries the export kind (currently always "durable-object"); the state field carries the lifecycle and defaults to "created" (live) when omitted:

  {
    "exports": {
      // Provision a new Durable Object class (`MyDO`)
      "MyDO": { "type": "durable-object", "storage": "sqlite" },
      // Delete Durable Object class (`OldGone`)
      "OldGone": { "type": "durable-object", "state": "deleted" },
      // Rename a Durable Object class (from `OldName` to `NewName`)
      "OldName": {
        "type": "durable-object",
        "state": "renamed",
        "renamed_to": "NewName"
      },
      "NewName": { "type": "durable-object", "storage": "sqlite" },
      // Transfer a Durable Object (`Outgoing`) to a new Worker (`target-worker`)
      "Outgoing": {
        "type": "durable-object",
        "state": "transferred",
        "transferred_to": "target-worker"
      },
      // Prepare to receive the transfer of a Durable Object (`Incoming`) from another Worker (`source-worker`)
      "Incoming": {
        "type": "durable-object",
        "state": "expecting-transfer",
        "storage": "sqlite",
        "transfer_from": "source-worker"
      }
    }
  }

  When a Worker declares Durable Object class bindings but no lifecycle for them (neither a migrations array nor an exports map), wrangler warns and now suggests a declarative exports entry for each class (previously it suggested a legacy migrations block).

  The deployment response now surfaces the server's reconciliation result — created namespaces, applied tombstones, structured per-scenario info entries, and a removable_entries hint for stale tombstones that are safe to delete from the config. Blocking errors return the structured per-class detail with scenario tags, suggested remediation, and any referencing-script context.

  wrangler versions upload also forwards exports. Declarative exports lifecycle changes are reconciled when the version is deployed (wrangler versions deploy or wrangler deploy), so a versions upload payload can declare new classes in exports without immediately provisioning them. An actor binding (durable_objects.bindings) to a class declared only in exports on the same versions upload is rejected with a clear error (code 100406) — the binding cannot be resolved until the namespace is provisioned. Either stage the new class via ctx.exports.X (no binding required) on versions upload and add the binding at deploy time, or use wrangler deploy to provision and bind in one step (the same constraint applies to the migrations flow).

  Multi-version deploys (wrangler versions deploy A@50% B@50%) where the selected versions disagree on declarative exports are rejected server-side with a clear message: deploy the version that changes exports at 100% first, then run the percentage-split deploy. This prevents traffic on one branch routing to code that references unprovisioned or just-deleted DO namespaces. Single-version (100%) deploys are unaffected.

  Local development (wrangler dev, vite dev and unstable_startWorker) reads Durable Object SQLite storage settings from the new exports field, so applications using the declarative flow get correct local-dev storage without needing to also declare a migrations block.

  @cloudflare/vitest-pool-workers also picks up Durable Object configuration from exports, so tests against an exports-only Worker run with the correct local SQLite storage and can reach unbound Durable Object classes via ctx.exports.X.

  wrangler types is also aware of exports. Live entries (including expecting-transfer, the receiving side of a two-phase transfer) are added to Cloudflare.GlobalProps.durableNamespaces, which types ctx.exports.X for unbound Durable Objects declared only via exports.

Patch Changes

• Updated dependencies [aa5d580, 6b0ce98, fd92d56, bfe48db, be3f792, 0277bfa, 98793d8, e1532eb]:
  • wrangler@​4.107.0
  • miniflare@​4.20260701.0

v0.17.0

Compare Source

Minor Changes

• #​14490 75d8cb0 Thanks @​petebacondarwin! - Make Workflow introspector get() async

  The introspectWorkflow(...).get() method now returns a promise, so callers must await it:

  const introspector = await introspectWorkflow(env.MY_WORKFLOW);
  
  // Before
  const instances = introspector.get();
  
  // After
  const instances = await introspector.get();

  This aligns Workflow introspection with the shared implementation used by createTestHarness().

Patch Changes

• #​14490 75d8cb0 Thanks @​petebacondarwin! - Support require("./x.wasm?module") in CommonJS dependencies

  Previously, only literal await import("./x.wasm?module") specifiers were rewritten through the static analysis path added in #​11094. CommonJS dependencies that use require("./x.wasm?module") reach the module-fallback service at runtime, where the ?module suffix went unhandled. The fallback either failed with No such module "<abs>/x.wasm?module"

✂ Note

PR body was truncated to here.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

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

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

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

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: rewriter/package-lock.json

npm warn Unknown env config "store". This will stop working in the next major version of npm. See `npm help npmrc` for supported config options.
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error
npm error While resolving: rewriter@0.0.0
npm error Found: vitest@3.2.7
npm error node_modules/vitest
npm error   dev vitest@"~3.2.0" from the root project
npm error   peer vitest@"3.2.7" from @vitest/browser@3.2.7
npm error   node_modules/@vitest/browser
npm error     peerOptional @vitest/browser@"3.2.7" from vitest@3.2.7
npm error   1 more (@vitest/ui)
npm error
npm error Could not resolve dependency:
npm error peer vitest@"^4.1.0" from @cloudflare/vitest-pool-workers@0.22.0
npm error node_modules/@cloudflare/vitest-pool-workers
npm error   dev @cloudflare/vitest-pool-workers@"^0.22.0" from the root project
npm error
npm error Fix the upstream dependency conflict, or retry this command with --force or --legacy-peer-deps to accept an incorrect (and potentially broken) dependency resolution.
npm error
npm error
npm error For a full report see:
npm error /runner/cache/others/npm/_logs/2026-08-20T23_52_04_940Z-eresolve-report.txt
npm error A complete log of this run can be found in: /runner/cache/others/npm/_logs/2026-08-20T23_52_04_940Z-debug-0.log