chore(deps): update typescript-projects

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@cloudflare/vitest-pool-workers (source)	0.16.13 → 0.16.15
@typescript-eslint/eslint-plugin (source)	8.60.1 → 8.61.0
@typescript-eslint/parser (source)	8.60.1 → 8.61.0
pnpm (source)	11.5.1 → 11.6.0
prettier (source)	3.8.3 → 3.8.4
semver	7.8.3 → 7.8.4
typescript-eslint (source)	8.60.1 → 8.61.0
wrangler (source)	4.98.0 → 4.100.0

---

Release Notes

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

v0.16.15

Compare Source

Patch Changes

• Updated dependencies [98c9afe, e305126, f3990b2, 4597f08, 25722ac, 41f75c0, 10b5538, 818c105, 2ae6099, 2047a32, 2047a32, e8561c2]:
  • wrangler@​4.100.0
  • miniflare@​4.20260611.0

v0.16.14

Compare Source

Patch Changes

• Updated dependencies [23aecac, b932e47, d076bcc, 24497d0, 4bb572f, 165adb2, 776098c, 0706fbf, 7993711, 48c4ff0, 8cf8c61, 8923f97, b205fb7, a61ac29]:
  • wrangler@​4.99.0
  • miniflare@​4.20260609.0

typescript-eslint/typescript-eslint (@​typescript-eslint/eslint-plugin)

v8.61.0

Compare Source

🚀 Features

• ast-spec: change type of UnaryExpression.prefix to always true (#​12372)

❤️ Thank You

• Kirk Waiblinger @​kirkwaiblinger

See GitHub Releases for more information.

You can read about our versioning strategy and releases on our website.

typescript-eslint/typescript-eslint (@​typescript-eslint/parser)

v8.61.0

Compare Source

This was a version bump only for parser to align it with other projects, there were no code changes.

See GitHub Releases for more information.

You can read about our versioning strategy and releases on our website.

pnpm/pnpm (pnpm)

v11.6.0

Compare Source

Minor Changes

• pnpm install completes without re-resolving when pnpm-lock.yaml was deleted but node_modules is intact: the up-to-date check now treats the current lockfile (node_modules/.pnpm/lock.yaml) — the record of what the previous install materialized — as the wanted lockfile, verifies the manifests still match it, restores pnpm-lock.yaml from it, and reports "Already up to date". Previously this scenario triggered a full resolution and a re-verification of every locked package against the registry.

• 615c669: Added support for configuring URL-scoped registry settings through npm_config_//… and pnpm_config_//… environment variables, for example:

  npm_config_//registry.npmjs.org/:_authToken=<token>
  pnpm_config_//registry.npmjs.org/:_authToken=<token>
  

  This provides a file-free way to supply registry authentication. Because the registry a value applies to is encoded in the (trusted) environment variable name, it is host-scoped by construction and cannot be redirected to another registry by repository-controlled config. The environment value is treated as trusted config: it takes precedence over a project/workspace .npmrc but is still overridden by command-line options. When the same key is provided through both prefixes, pnpm_config_ wins.

• Raised the default network concurrency from min(64, max(cpuCores * 3, 16)) to min(96, max(cpuCores * 3, 64)). Package downloads are I/O-bound, not CPU-bound, so deriving the floor from the core count left machines with few cores (for example 4-vCPU CI runners) downloading only 16 tarballs at a time and unable to saturate a low-latency registry. The networkConcurrency setting still overrides the default.

Patch Changes

• Improved the warning printed when a project .npmrc uses an environment variable in a registry/proxy URL or in registry credentials. The message now explains why the setting was ignored and how to migrate it to a trusted source — for example by moving the line to the user-level ~/.npmrc or running pnpm config set "<key>" <value> — with a link to https://pnpm.io/npmrc. The pnpm config set example is only suggested when the key has no ${...} placeholder, so the snippet is always safe to copy-paste.
• Print a "Lockfile passes supply-chain policies (verified 2h ago)" message when lockfile verification is skipped because a cached verdict for the same lockfile content and policy is reused. Previously the cached short-circuit was completely silent, which made it look like the policy gate never ran #​12324.
• Platform-specific optional dependencies are now skipped even when their os/cpu/libc fields are missing from the registry metadata or the lockfile. Some registries strip these fields from the package metadata, which made pnpm download and install the binaries of every platform regardless of supportedArchitectures. The missing platform fields of an optional dependency are now inferred from its name (e.g. @nx/nx-win32-arm64-msvc → os: win32, cpu: arm64), so foreign-platform binaries are skipped without even downloading them #​11702.

v11.5.3

Compare Source

Patch Changes

• Stopped expanding environment variables in repository-controlled registry/proxy request destinations and registry credential values from .npmrc, and in workspace registry URLs from pnpm-workspace.yaml. Move dynamic registry URL and token configuration to trusted user, global, CLI, or environment config.

• Resolve package-manager bootstrap dependencies with trusted user or CLI registry and network config, and reject package-manager env-lockfile records that do not use registry package paths with integrity-only resolutions before auto-switch execution.

• Avoid writing packageManagerDependencies to pnpm-lock.yaml when package manager policy is set to onFail: ignore or pmOnFail: ignore #​12228.

• Avoid running dependency-status auto-install when the dependency status is unavailable without a project manifest.

• Using the $ version reference syntax in overrides (e.g. "react": "$react") now prints a deprecation warning. The syntax still works, but catalogs are the recommended way to keep an overridden version in sync with the rest of the workspace. Reference a catalog entry with the catalog: protocol instead.

• Fixed pnpm config get globalconfig to return the global config.yaml path again pnpm/pnpm#11962.

• Fixed bare --color so it does not consume the following CLI flag, allowing command shorthands like --parallel to expand correctly and forms like pnpm --color with current <command> to dispatch the inner command instead of failing with MISSING_WITH_CURRENT_CMD.

• Fix pnpm install ignoring enableGlobalVirtualStore toggle by including it in the workspace state settings check #​12142.

• Security: pnpm now verifies the npm registry signature of a package-manager binary before spawning it, so a cloned repository cannot make pnpm download and execute an arbitrary native binary.

  This covers two paths that select an executable from repository-controlled input:

  • pacquet install engine — declaring pacquet (or @pnpm/pacquet) in configDependencies opts in to pnpm's Rust install engine. pnpm now verifies that the installed pacquet shim and the host's @pacquet/<platform>-<arch> binary carry a valid npm registry signature for their exact name@version, and refuses to run pacquet (failing the command) if the signature does not verify or cannot be checked. The only graceful fallback to pnpm's own engine is when pacquet has no binary for the current platform.
  • automatic version switch / self-update — the packageManager / devEngines.packageManager field makes pnpm download and run a specific pnpm version. pnpm now verifies the registry signature of pnpm, @pnpm/exe, and the host platform binary before installing/spawning them, and refuses to run an engine whose signature does not match a published, signed release. The check runs only on an actual download (store cache miss), so it does not add a network round trip to every command.

  In both cases the signature is verified over the installed integrity, against npm's public signing keys that ship embedded in the pnpm CLI (like corepack), so bytes substituted via a tampered lockfile or a repository-controlled registry fail verification — and a registry the user did not vouch for cannot supply its own signing keys. The signed packument is fetched from the configured registry, so an npm mirror works transparently. Verification fails closed: if it cannot be completed (for example, the registry is unreachable), the command fails rather than running an unverified binary. The embedded keys are kept current by a release-time check against npm's signing-keys endpoint.

• Made peer-dependent deduplication deterministic. When a peer-suffixed package variant was a subset of two or more mutually incompatible larger variants, the variant it collapsed into depended on the order importers were resolved in, which varies between machines. This could resolve the same workspace to different lockfiles on different platforms and make pnpm dedupe --check alternate between passing and failing.

• Reject invalid package names and versions from staged tarball manifests before deriving filenames for pnpm stage download.

• Clarified in CLI help that the pnpm store is trusted shared state and store integrity checks are corruption detection, not a tamper boundary for untrusted store writers.

• Reject reserved manifest bin names ("", ".", "..", and scoped forms such as @scope/..) when resolving a package's bins. These names previously passed the bin-name guard and, when joined to the global bin directory during global remove/update/add operations, could resolve to the global bin directory itself or its parent and have it recursively deleted.

• Require trusted package identity before package-name allowBuilds entries can approve lifecycle scripts for git, git-hosted tarball, direct tarball, and local directory artifacts. To approve one of those artifacts explicitly, use its peer-suffix-free lockfile depPath as the allowBuilds key. Lockfile verification now rejects lockfiles where a registry-style dependency path (name@semver) is backed by a git, directory, or git-hosted tarball resolution (ERR_PNPM_RESOLUTION_SHAPE_MISMATCH), so the dependency path is a reliable artifact identity by the time scripts can run.

• Security: pnpm now verifies the OpenPGP signature of a downloaded Node.js runtime's SHASUMS256.txt before trusting its integrity hashes.

  When a repository requests a Node.js runtime (e.g. via devEngines.runtime / useNodeVersion), the download mirror is repository-configurable through node-mirror:<channel>. The integrity of the downloaded binary was only checked against SHASUMS256.txt fetched from that same mirror — a circular check that a malicious mirror could satisfy by serving a tampered binary together with a matching SHASUMS256.txt. pnpm then executes the binary (for example to run lifecycle scripts).

  pnpm now fetches SHASUMS256.txt.sig and verifies the detached OpenPGP signature against the Node.js release team's public keys, which ship embedded in the pnpm CLI. A mirror that serves a tampered binary cannot also produce a valid signature, so the download fails to verify. The embedded keys are kept current by a release-time check against the canonical nodejs/release-keys list.

  The musl variants from the hardcoded unofficial-builds.nodejs.org mirror are not repository-configurable and are signed by a different key, so they continue to be trusted over TLS.

v11.5.2

Compare Source

Patch Changes

• Peer dependency resolution now reuses the peer contexts already recorded in the lockfile when those providers are still present in the dependency graph and still satisfy the peer ranges. This avoids unnecessary peer-context rewrites during lockfile regeneration. Current manifest choices remain authoritative: a newly added, explicitly updated, or aliased direct provider, a changed nested provider, or a locked version that no longer satisfies the range still takes precedence.

• The lockfile verifier now checks that a registry entry pinning an explicit tarball URL points at the artifact the registry's own metadata lists for that name@version. Previously a tampered lockfile could pair a trusted name@version with an attacker-chosen tarball URL (and a matching integrity for those bytes), so the install fetched the attacker's bytes. A mismatch — or any entry that can't be confirmed against the registry — is rejected with ERR_PNPM_TARBALL_URL_MISMATCH. Non-registry resolutions (file:, git-hosted, etc.) and registry entries without an explicit tarball URL (the URL is reconstructed from name+version+registry, so it is inherently bound) are unaffected; non-standard registry tarball URLs (npm Enterprise, GitHub Packages) still pass because they match the metadata.

• Fix pnpm update --recursive --lockfile-only <pkg>@&#8203;<version> crashing with Invalid Version when the catalog entry for <pkg> is a version range (e.g. ^21.2.10) and catalogMode is strict or prefer. The catalog–version comparison now skips the equality check when either side is a range rather than passing a range to semver.eq(), so range specifiers fall through to the existing mismatch handling instead of throwing #​11570.

• Avoided a Node.js crash when pnpm exits after network requests on Windows.

• Fixed packages being materialized into the virtual store without their root-level files (package.json, LICENSE, README, root entrypoints) when multiple pnpm install processes ran against the same store/workspace concurrently. The fast import path used to destructively empty the shared target directory, so a concurrent importer could wipe files another importer had already written; if the surviving files included the package.json completion marker, every later install treated the broken directory as complete and never repaired it. The fast path now imports directly only when it can create the target directory exclusively, and otherwise builds the package in a private temp directory and atomically renames it into place #​12197.

• Fix dependency build scripts not running under the global virtual store (enableGlobalVirtualStore).

  In a workspace install, dependency build scripts are deferred to a single rebuild pass (buildProjects). That pass resolved each package's location from the classic node_modules/.pnpm/<depPathToFilename> layout, which does not exist under the global virtual store — so native dependencies (e.g. packages using node-gyp / prebuild-install) were never built and failed to load at runtime (Cannot find module .../build/Release/*.node).

  buildProjects now resolves the global-virtual-store projection directory (<storeDir>/links/<hash>, computed with the same graph hash the installer uses) when enableGlobalVirtualStore is set, and serializes concurrent builds of the same shared projection so parallel workspace projects don't race on the same directory.

• Don't promote a runtime: dependency (such as the Node.js version from devEngines.runtime or pnpm runtime set) into a catalog when catalogMode is strict or prefer. A runtime: dependency round-trips to devEngines.runtime, which only recognizes the runtime: protocol; cataloging it rewrote the manifest entry to catalog:, which broke that round-trip, stranded it in devDependencies, and left devEngines.runtime untouched.

• Skip lockfile minimumReleaseAge/trustPolicy verification for non-registry tarball protocols (for example file:), so local tarball dependencies are not incorrectly checked against npm registry metadata.

prettier/prettier (prettier)

v3.8.4

Compare Source

npm/node-semver (semver)

v7.8.4

Compare Source

Bug Fixes

• e583226 #​874 reject numeric segments after x-ranges (@​pupuking723)

typescript-eslint/typescript-eslint (typescript-eslint)

v8.61.0

Compare Source

This was a version bump only for typescript-eslint to align it with other projects, there were no code changes.

See GitHub Releases for more information.

You can read about our versioning strategy and releases on our website.

cloudflare/workers-sdk (wrangler)

v4.100.0

Compare Source

Minor Changes

• #​14119 2047a32 Thanks @​tahmid-23! - Serve local R2 bucket objects publicly via the dev server

  When running wrangler dev locally, objects in each local R2 binding are now reachable under /cdn-cgi/local/r2/public/<bucket-id>/<key> on the existing dev server, simulating a public bucket. The <bucket-id> is the bucket's bucket_name when set, otherwise its binding. Bindings configured with remote: true are not exposed.

• #​14202 e8561c2 Thanks @​jamesopstad! - Add experimental --x-new-config flag for authoring config in TypeScript

  This is an experimental, opt-in feature. When enabled, wrangler dev, wrangler build, wrangler deploy, wrangler versions upload, and wrangler versions deploy load the Worker's configuration from a cloudflare.config.ts file instead of wrangler.json / wrangler.jsonc / wrangler.toml. Additionally, an optional wrangler.config.ts file can be provided for Wrangler-specific dev/build configuration.

  • cloudflare.config.ts (required) — Worker runtime configuration (bindings, triggers, observability, placement, limits, compatibility, routes, etc.). Authored via defineWorker from wrangler/experimental-config.
  • wrangler.config.ts (optional) — Tooling / bundling / dev-server configuration (noBundle, minify, alias, define, rules, tsconfig, build, dev, assetsDirectory, etc.). Authored via defineWranglerConfig from wrangler/experimental-config.

  Per-environment configuration is via ctx.mode branching inside the function form of either file.

  Example cloudflare.config.ts:

  import { defineWorker, bindings } from "wrangler/experimental-config";
  import * as entrypoint from "./src/index.ts" with { type: "cf-worker" };
  
  export default defineWorker((ctx) => ({
  	name: "my-worker",
  	entrypoint,
  	compatibilityDate: "2026-05-18",
  	env: {
  		MY_KV: bindings.kv(),
  		MY_TEXT: bindings.text(`The mode is ${ctx.mode}`),
  	},
  }));

  Example wrangler.config.ts:

  import { defineWranglerConfig } from "wrangler/experimental-config";
  
  export default defineWranglerConfig({
    minify: true,
    assetsDirectory: "./public",
  });

  Because this is experimental, the flag, the config formats, and the wrangler/experimental-config exports may change in any release.

Patch Changes

• #​14185 98c9afe Thanks @​penalosa! - Use the shared env-credential resolver from @cloudflare/workers-auth

  No user-facing behaviour change. Credential resolution order (global API key + email → CLOUDFLARE_API_TOKEN → stored OAuth token) is preserved.

• #​14184 e305126 Thanks @​penalosa! - Add an experimental cf-wrangler delegate entrypoint for projects that can't use @cloudflare/vite-plugin (service workers, old compatibility dates, Python, Rust, etc.).

  cf-wrangler dev starts the same local dev server as wrangler dev — it sits directly on wrangler's internal dev server, so the bundling and runtime behaviour are identical — but exposes a deliberately narrow CLI surface (--mode, --port, --host, --local) for a parent CLI to delegate to, and other dev server config options are read from the wrangler config file.

  This replaces the separate @cloudflare/wrangler-bundler package. This is an internal integration point and is not intended to be run directly by users.

• #​14246 f3990b2 Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260609.1	1.20260610.1

• #​14256 4597f08 Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260610.1	1.20260611.1

• #​14243 25722ac Thanks @​com6056! - Fix a memory leak that could make long-running headless wrangler dev sessions unresponsive

  Long-running wrangler dev sessions with no DevTools attached (for example using the containers feature under sustained traffic) could gradually consume unbounded memory and eventually stop accepting connections. The inspector proxy now only enables network tracking while a DevTools client is connected, so the buildup no longer happens. Interactive debugging is unaffected. Fixes #​14191.

• #​14230 41f75c0 Thanks @​dario-piotrowicz! - Improve D1 error messages for missing or conflicting options

  Error messages for d1 execute, d1 export, d1 time-travel restore, and d1 insights now clearly state which option is missing or conflicting, explain why the combination is invalid, and suggest how to fix the issue.

  Additionally, duration validation errors in d1 insights are now thrown as UserError instead of plain Error, ensuring they are displayed cleanly to users rather than as unexpected crashes.

• #​14213 10b5538 Thanks @​dario-piotrowicz! - Improve authentication error messages with specific failure reasons

  When authentication fails (e.g. during wrangler dev --remote or when using remote bindings), the error message now explains exactly what went wrong -- whether no credentials were found, the token expired, or the environment is non-interactive -- and lists actionable steps to fix it, including a wrangler whoami tip.

  Previously, auth failures could produce multiple confusing errors (e.g. "Failed to fetch auth token: 400 Bad Request" followed by "Failed to start the remote proxy session"). Now a single, clear error is shown.

• #​14233 818c105 Thanks @​dario-piotrowicz! - Improve R2 Sippy error messages

  Now error messages in wrangler r2 bucket sippy follow a consistent pattern: they describe what is missing, name the exact --flag to use, and provide context (e.g. example values, links to the dashboard). Previously, many errors said only "Error: must provide --flag." with no guidance on what the flag does or how to obtain the value.

• #​14259 2ae6099 Thanks @​emily-shen! - Move worker build step earlier in deploy/upload step, before upload specific config validation

• Updated dependencies [f3990b2, 4597f08, 2047a32]:

  • miniflare@​4.20260611.0

v4.99.0

Compare Source

Minor Changes

• #​14169 0706fbf Thanks @​edmundhung! - Introduce createTestHarness() for integration testing Workers

  It runs Workers in a local preview environment using production build output and works with both Wrangler projects and Workers built by the Cloudflare Vite plugin.

  Use it from any Node.js test runner to send requests to individual Workers, trigger scheduled events, reset the server between tests, and mock outbound requests with libraries that intercept globalThis.fetch(), such as MSW.

  You can also capture structured logs from your Workers with getLogs(), or dump out a diagnostic timeline with debug() when tests fail:

  import { createTestHarness } from "wrangler";
  
  const server = createTestHarness({
    workers: [
      { configPath: "./dist/web_worker/wrangler.json" },
      { configPath: "./dist/api_worker/wrangler.json" },
    ],
  });
  
  await server.listen();
  await server.fetch("http://example.com");
  
  const apiWorker = server.getWorker("api-worker");
  await apiWorker.fetch("http://example.com/users/123");
  await apiWorker.scheduled({ cron: "0 0 * * *" });
  
  server.getLogs();
  
  if (testFailed) {
    server.debug();
  }
  
  await server.reset();
  await server.close();

• #​14174 8cf8c61 Thanks @​oliy! - Surface pipeline status and failure reasons in wrangler pipelines list and wrangler pipelines get

  wrangler pipelines list now includes a Status column, and when any pipelines are in a failed state it prints a summary of each failing pipeline along with the reason reported by the API.

  wrangler pipelines get now shows the pipeline Status in the general details and, for failed pipelines, highlights the failure with the reason returned by the server so it is clear why a pipeline is not running.

• #​14211 a61ac29 Thanks @​james-elicx! - Add --version-tag support to wrangler versions deploy to deploy a version by its tag

  You can now roll out or roll back a version by the tag it was uploaded with (e.g. a commit SHA passed to --tag at upload time) instead of first looking up its Version ID:

  wrangler versions deploy --version-tag <sha>@&#8203;100%

  The tag is resolved to a Version ID against the worker's deployable versions, and the <version-tag>@&#8203;<percentage> shorthand works just like the existing <version-id>@&#8203;<percentage> notation, including splitting traffic across multiple --version-tag values. If a tag matches no deployable version, or matches more than one, the command errors and asks you to deploy by Version ID directly. Note that tags can only be resolved against recent (deployable) versions — older versions that have aged out of that window must still be deployed by Version ID.

Patch Changes

• #​14163 23aecac Thanks @​emily-shen! - Print deploy warnings even in non-interactive contexts when strict mode is off

  Currently, wrangler deploy checks whether the incoming deploy configuration has destructive conflicts with the current configuration. Previously, we only performed this check in interactive contexts, or if the --strict flag was passed in. Now this warning is always printed, and it remains non-blocking in non-interactive contexts.

• #​14173 b932e47 Thanks @​gpanders! - Handle API validation errors from wrangler containers ssh

  Wrangler now lets the Containers API validate SSH instance IDs and preserves raw API error bodies such as INVALID_INSTANCE_ID when reporting validation failures.

• #​14192 d076bcc Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260603.1	1.20260605.1

• #​14217 24497d0 Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260605.1	1.20260608.1

• #​14231 4bb572f Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260608.1	1.20260609.1

• #​14195 165adb2 Thanks @​dario-piotrowicz! - Show actionable error message when authentication fails during remote dev

  When wrangler dev with remote bindings encountered an authentication error (expired token, revoked OAuth, or invalid API token), the user saw a generic "A request to the Cloudflare API failed" message with no indication that authentication was the problem.

  Now, authentication failures during remote dev display a clear error message with actionable steps.

• #​14034 776098c Thanks @​matingathani! - Fix wrangler types --check reporting types as out of date in multi-worker setups

  Previously, running wrangler types --check -c primary/wrangler.jsonc in a multi-worker project would incorrectly report types as out of date, even when they were current. This happened because the secondary worker config paths (passed via additional -c flags during generation) were not stored in the generated types file header, so --check had no way to resolve the secondary workers' service bindings when verifying the hash.

  The fix stores secondary config paths in the generated file's header comment so that --check can recover them automatically. Users no longer need to re-pass every -c flag when running --check — only the primary config is required.

• #​14053 7993711 Thanks @​fallintoplace! - Prevent delete-only wrangler secret bulk input from creating a new Worker

  Previously, wrangler secret bulk could create a draft Worker when the input only deleted secrets and the target Worker name did not exist. Delete-only bulk secret operations now leave Worker-not-found as an error instead of creating a new Worker.

• #​14055 8923f97 Thanks @​dario-piotrowicz! - Preserve all deployment-affecting CLI flags in the interactive deploy config flow

  When running wrangler deploy without a config file and going through the interactive setup flow, CLI flags beyond --compatibility-flags (such as --routes/--route, --domains/--domain, --triggers, --var, --define, --alias, --jsx-factory, --jsx-fragment, --tsconfig, --minify, --upload-source-maps, --no-bundle, --logpush, --keep-vars, --legacy-env, and --dispatch-namespace) were silently dropped. These flags are now persisted to the generated wrangler.jsonc config file (where a config field equivalent exists) and included in the suggested CLI command when the user declines config file generation.

• #​14196 b205fb7 Thanks @​odiak! - Validate JSON stdin values for wrangler secret bulk

  JSON input piped through stdin now validates that secret values are strings or null before sending them to the API, matching the existing behavior for file input.

• Updated dependencies [d076bcc, 24497d0, 4bb572f, 48c4ff0]:

  • miniflare@​4.20260609.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "before 9am on tuesday"
• 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 these updates again.

---

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

---

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