Sourced from react-doctor's releases.

react-doctor@0.7.1

Patch Changes

• #1062 6b21b70 Thanks @​devin-ai-integration! - Surface when a scan target had no discoverable React project, so a gated-off run can't pass for a clean one.

  • The JSON report now carries reactDetected: false (additive optional field on schemaVersion 1 and 2) when no scanned project resolved a React or Preact runtime — the case where every React-runtime rule family gates off and the report would otherwise be byte-indistinguishable from a genuinely clean scan. It's true when any project resolved a runtime, and absent when nothing was scanned or the run errored. Consumers gating on the report (CI, verifiers, pre-commit hooks) should treat reactDetected === false as "wrong scan target", not "all clear"; per-project detail is already available via projects[].project.reactVersion / preactVersion.
  • The CLI prints a stderr warning in the same case: "No React project detected at — React rules were gated off; this is not the same as a clean scan."
  • The programmatic API mirrors the signal: diagnose() results carry reactDetected (DiagnoseResult.reactDetected, per-project on ProjectResultOk, aggregate on DiagnoseProjectsResult — absent when no project scanned successfully), and the hasReactRuntime(project) predicate is exported from react-doctor/api and @react-doctor/api.

• Updated dependencies [c0c3fc1]:

  • oxlint-plugin-react-doctor@0.7.1
  • deslop-js@0.7.1

react-doctor@0.7.0

Patch Changes

• #1060 ced746f Thanks @​rayhanadev! - The whole cache stack now survives CI's fresh checkouts, so the GitHub Action's persisted REACT_DOCTOR_CACHE_DIR actually warms every layer instead of only the content-addressed ones. The whole-repo scan-result cache moves under the shared per-project cache root (honoring REACT_DOCTOR_CACHE_DIR like the lint, sidecar, dead-code, and supply-chain caches — previously it silently escaped the action's cache into node_modules/.cache or the OS temp dir), and its key drops every stat-based fingerprint that a re-clone rotates: config files and gitignored dotenv files are now content-hashed, and the toolchain is keyed by package versions (matching the lint ruleset hash) rather than install mtimes. The stat-fingerprinted dead-code caches gain mtime repair (the ninja/restat pattern): entries carry a content-hash witness, and a stat mismatch over identical bytes — every file after a fresh checkout — re-hashes once, accepts the entry, and persists the refreshed stat so the cost is paid once per checkout, not per run. This covers core's whole-project dead-code result cache (per-file (mtime, size, hash) records replacing the stats-in-key fingerprint) and deslop-js's incremental summary store (parse summaries, package-reference facts, and the manifest/bundler-config fingerprints feeding the collect/resolution hashes). Expired supply-chain score entries are also pruned past their TTL so restored cache directories stop accumulating dead purls. Everything stays fail-open and byte-identical to an uncached scan; on a re-cloned repo with one changed file, a warm scan now replays ~100% of lint, sidecar, and parse work instead of starting cold.

• #1056 20d81f6 Thanks @​rayhanadev! - Hardened the dead-code result cache key against two silent-staleness classes. The fingerprinted extension and manifest name lists are now imported from deslop-js/analyzed-inputs — a new dependency-free subpath export assembled from the same constants deslop's own readers consume — so a deslop upgrade that widens its walk can never under-invalidate the cache. And the key now includes @react-doctor/core's own version, so upgrading react-doctor re-analyzes instead of replaying cached diagnostics shaped by an older core's post-processing. The cache schema-version constant remains for cache-format changes only.

• #1053 e257a5e Thanks @​rayhanadev! - Rescans now skip the dead-code analysis entirely when nothing it reads has changed. The pass persists its diagnostics keyed by a fingerprint over the analyzed source tree (stat-based, so additions, deletions, and edits all invalidate), the project's manifests, tsconfigs, lockfiles, knip/entry/ignore configuration, and the analyzer version — on an unchanged-input rerun the stored result replays instead of re-walking the whole import graph, cutting several seconds off warm rescans of large repos. Only complete, successful passes are stored; REACT_DOCTOR_NO_CACHE (or the granular REACT_DOCTOR_NO_DEAD_CODE_CACHE) disables it.

• #1057 ce49250 Thanks @​rayhanadev! - Dead-code analysis is now incremental across scans. deslop-js gains an opt-in incrementalCachePath config field: one stat walk per run (following directory symlinks, like the glob scans it stands in for) validates four independently keyed layers — per-file parse summaries (mtime+size), the collected file list, the module-resolution map (dropped whenever the file set or a bundler/tsconfig-like config changes, since resolution is file-set-dependent), and the per-file package-reference facts behind the unused-dependency content scans. The same walk also answers the stale-package file-discovery globs (config/docs/rescue/package.json/nx/tsconfig scans, verified byte-identical against fast-glob), so a cached run never re-walks the tree for them. Entry resolution deliberately stays live every run (it reads config/doc/sibling-source content no fingerprint can validate); on cached runs it moves to a dedicated worker thread so its filesystem work overlaps the main-thread analysis instead of serializing after it. Every layer fails open — corrupt, truncated, or version/config-mismatched stores degrade to a fresh computation, never a wrong result — writes are atomic and skipped when clean, and results are byte-identical to an uncached run. Unused-export detection also indexes re-export edges by source module, dropping an O(entry points × edges) scan that dominated the detector on large repos.

  react-doctor points the analysis worker at a per-project summary store next to the existing whole-result dead-code cache, so a changed-files rescan of a large repo re-parses only what changed (sentry, 9k files: ~8.0s → ~3.2s with 0-10 files edited; ~4.0s after adding a file; the cache-fill run costs the same as an uncached scan). The worker also stops running the discarded DRY-pattern redundancy detectors (reportRedundancy: false), which shrinks the summary store by dropping fields only those detectors read, and reports the cache outcome as deadCode.summaryCacheHits / deadCode.summaryCacheMisses in anonymized telemetry (absent whenever no analysis consulted the store). REACT_DOCTOR_NO_CACHE (or the granular REACT_DOCTOR_NO_DEAD_CODE_CACHE) disables it.

• #1054 8c004f0 Thanks @​rayhanadev! - Instant reruns now also work with uncommitted changes: the whole-repo scan-result cache no longer requires a clean worktree — it keys on the exact dirty state (every modified, staged, renamed, deleted, and untracked path plus a hash of its content), so rescanning the same work-in-progress tree hits the cache while any edit still invalidates it.

• #1052 1571119 Thanks @​rayhanadev! - Restore instant reruns on large repos: raise runGit's output cap so the whole-repo scan-result cache works past ~15k tracked files.

  The cache's clean-worktree gates shell out to git through a helper that used Node's default 1 MiB maxBuffer. On repos with roughly 15-25k tracked files (getsentry/sentry: 20,343), git ls-files -v alone exceeds that, execFileSync throws ENOBUFS, the helper swallows it into null, and the gates read null as "hidden tracked state" — so the cache silently never stored or served a scan on exactly the repos where the instant-rerun path saves the most time. The helper now runs with an explicit 64 MiB cap, which clears monorepos with hundreds of thousands of files while still bounding a pathological child process.

• #1058 ea9a775 Thanks @​rayhanadev! - Warm rescans now skip the cross-file lint sidecar for files whose dependencies are unchanged. Previously the per-file lint cache replayed most rules but re-linted EVERY file with the cross-file ruleset (no-barrel-import, the Next.js metadata/Suspense rules, no-mutating-reducer-state, the React Native text rules) on every scan, because a sibling edit can flip an unchanged file's verdict. Each file now carries a dependency fingerprint — the exact set of filesystem probes (resolved import targets, barrel chains, ancestor layouts, nearest package.json/tsconfig, and the negative resolution candidates that catch shadowing) its cross-file rules consulted — and the sidecar replays the stored diagnostics when every probe still answers the same, re-linting only files whose dependency set changed. Every entry fails open (corrupt store, unparseable file, partial lint → fresh re-lint), a cross-file rule without a registered dependency collector re-lints everywhere, and REACT_DOCTOR_NO_CACHE (or the granular REACT_DOCTOR_NO_SIDECAR_CACHE) disables it.

• #1059 bdf8074 Thanks @​rayhanadev! - Added cache-temperature telemetry to the per-scan Sentry wide event, so cache effectiveness is queryable at a glance instead of being inferred from per-subsystem dims. cache.temperature classifies every scan as turbo (whole-repo scan-result replay — now marked by an explicit wholeRepoCacheHit flag on the replay path, never inferred from absent dims), warm (any incremental reuse across the per-file lint, sidecar, or dead-code caches), cold (caches on, zero reuse), or disabled (the global REACT_DOCTOR_NO_CACHE off-switch). cache.warmth is the numeric headline magnitude in [0, 1] — the plain mean of the known subsystem reuse fractions, skipping subsystems that never consulted a cache. The existing per-subsystem dims (lint.cacheHitRatio, lint.sidecarReplayRatio, deadCode.cacheHit, deadCode.summaryCacheHits/Misses) are unchanged. Telemetry-only: no new counters, no JSON-report or cache-schema changes.

• Updated dependencies [ced746f, 20d81f6, ce49250]:

  • deslop-js@0.7.0
  • oxlint-plugin-react-doctor@0.7.0

react-doctor@0.6.3

Patch Changes

• #1045 fc75a3e Thanks @​rayhanadev! - Balance lint batches by file size (LPT) so one oversized batch no longer sets the whole scan's wall clock. The full-scan batcher greedily filled 100-file chunks in discovery order, so a directory of large files (generated modules, vendored bundles, big test fixtures — adjacent in git ls-files order) all landed in ONE batch: on a 619-file corpus with six ~240 KB files that straggler batch ran ~7.5 s while the other six workers finished in ~1 s and idled — and a big enough cluster can trip the 60 s per-batch timeout and drop files. The planner now keeps the same batch count (and therefore the same subprocess count and CPU) but assigns files largest-first to the least-loaded batch, so every batch carries an even share of files and bytes: 2.2× faster wall clock on the skewed corpus (9.7 s → 4.3 s), no measurable change on uniform repos, and diagnostics verified byte-identical on both. Splitting into MORE batches to feed idle workers was measured to regress (each extra concurrent subprocess pays a contended cold start that outweighs its smaller file share) and is deliberately not done. REACT_DOCTOR_LINT_BATCH_ORDERING=arrival rolls back to the old greedy chunking; the previous opt-in cost mode (sort-descending-then-chunk, which concentrated the heavy files instead of spreading them) is superseded by the balanced plan.

• #1046 59e8178 Thanks @​rayhanadev! - Stop lint's pre-spawn setup from starving the overlapped security-scan and supply-chain passes.

  The security scan already runs on a cooperative background fiber that overlaps the lint pass, but a forked fiber only advances when the main thread yields — and lint's synchronous pre-spawn prefix (full-scan file discovery plus the per-file cache's content-hash partition over every candidate file) held the event loop until the first oxlint subprocess spawned. The overlapped passes now start immediately: the lint runner hands the loop back once before discovery and yields on the shared cooperative time budget while hashing, and the security scan's own directory walk (previously one unyielding readdir+classify burst before its first budget checkpoint) yields walk-progress markers so large trees can't stall lint subprocess draining or concurrently-scanning sibling projects. Diagnostics are byte-identical and the report order is unchanged.

• Updated dependencies [173cc0a, 173cc0a, 173cc0a, 173cc0a, 173cc0a, 173cc0a, b4faf74, 173cc0a, 173cc0a, 173cc0a, 173cc0a, 173cc0a, 173cc0a, 173cc0a, 173cc0a, b4faf74, b4faf74, 072d37e, 2980d0f, 5fec491, 05f6399, a1c8ee1, fa61c20, ac71a3b, d8628d7, ebeee56, da3b19c, 6a9a73b, 173cc0a, 173cc0a]:

... (truncated)

Sourced from react-doctor's changelog.

0.7.1

Patch Changes

• #1062 6b21b70 Thanks @​devin-ai-integration! - Surface when a scan target had no discoverable React project, so a gated-off run can't pass for a clean one.

  • The JSON report now carries reactDetected: false (additive optional field on schemaVersion 1 and 2) when no scanned project resolved a React or Preact runtime — the case where every React-runtime rule family gates off and the report would otherwise be byte-indistinguishable from a genuinely clean scan. It's true when any project resolved a runtime, and absent when nothing was scanned or the run errored. Consumers gating on the report (CI, verifiers, pre-commit hooks) should treat reactDetected === false as "wrong scan target", not "all clear"; per-project detail is already available via projects[].project.reactVersion / preactVersion.
  • The CLI prints a stderr warning in the same case: "No React project detected at — React rules were gated off; this is not the same as a clean scan."
  • The programmatic API mirrors the signal: diagnose() results carry reactDetected (DiagnoseResult.reactDetected, per-project on ProjectResultOk, aggregate on DiagnoseProjectsResult — absent when no project scanned successfully), and the hasReactRuntime(project) predicate is exported from react-doctor/api and @react-doctor/api.

• Updated dependencies [c0c3fc1]:

  • oxlint-plugin-react-doctor@0.7.1
  • deslop-js@0.7.1

0.7.0

Patch Changes

• #1060 ced746f Thanks @​rayhanadev! - The whole cache stack now survives CI's fresh checkouts, so the GitHub Action's persisted REACT_DOCTOR_CACHE_DIR actually warms every layer instead of only the content-addressed ones. The whole-repo scan-result cache moves under the shared per-project cache root (honoring REACT_DOCTOR_CACHE_DIR like the lint, sidecar, dead-code, and supply-chain caches — previously it silently escaped the action's cache into node_modules/.cache or the OS temp dir), and its key drops every stat-based fingerprint that a re-clone rotates: config files and gitignored dotenv files are now content-hashed, and the toolchain is keyed by package versions (matching the lint ruleset hash) rather than install mtimes. The stat-fingerprinted dead-code caches gain mtime repair (the ninja/restat pattern): entries carry a content-hash witness, and a stat mismatch over identical bytes — every file after a fresh checkout — re-hashes once, accepts the entry, and persists the refreshed stat so the cost is paid once per checkout, not per run. This covers core's whole-project dead-code result cache (per-file (mtime, size, hash) records replacing the stats-in-key fingerprint) and deslop-js's incremental summary store (parse summaries, package-reference facts, and the manifest/bundler-config fingerprints feeding the collect/resolution hashes). Expired supply-chain score entries are also pruned past their TTL so restored cache directories stop accumulating dead purls. Everything stays fail-open and byte-identical to an uncached scan; on a re-cloned repo with one changed file, a warm scan now replays ~100% of lint, sidecar, and parse work instead of starting cold.

• #1056 20d81f6 Thanks @​rayhanadev! - Hardened the dead-code result cache key against two silent-staleness classes. The fingerprinted extension and manifest name lists are now imported from deslop-js/analyzed-inputs — a new dependency-free subpath export assembled from the same constants deslop's own readers consume — so a deslop upgrade that widens its walk can never under-invalidate the cache. And the key now includes @react-doctor/core's own version, so upgrading react-doctor re-analyzes instead of replaying cached diagnostics shaped by an older core's post-processing. The cache schema-version constant remains for cache-format changes only.

• #1053 e257a5e Thanks @​rayhanadev! - Rescans now skip the dead-code analysis entirely when nothing it reads has changed. The pass persists its diagnostics keyed by a fingerprint over the analyzed source tree (stat-based, so additions, deletions, and edits all invalidate), the project's manifests, tsconfigs, lockfiles, knip/entry/ignore configuration, and the analyzer version — on an unchanged-input rerun the stored result replays instead of re-walking the whole import graph, cutting several seconds off warm rescans of large repos. Only complete, successful passes are stored; REACT_DOCTOR_NO_CACHE (or the granular REACT_DOCTOR_NO_DEAD_CODE_CACHE) disables it.

• #1057 ce49250 Thanks @​rayhanadev! - Dead-code analysis is now incremental across scans. deslop-js gains an opt-in incrementalCachePath config field: one stat walk per run (following directory symlinks, like the glob scans it stands in for) validates four independently keyed layers — per-file parse summaries (mtime+size), the collected file list, the module-resolution map (dropped whenever the file set or a bundler/tsconfig-like config changes, since resolution is file-set-dependent), and the per-file package-reference facts behind the unused-dependency content scans. The same walk also answers the stale-package file-discovery globs (config/docs/rescue/package.json/nx/tsconfig scans, verified byte-identical against fast-glob), so a cached run never re-walks the tree for them. Entry resolution deliberately stays live every run (it reads config/doc/sibling-source content no fingerprint can validate); on cached runs it moves to a dedicated worker thread so its filesystem work overlaps the main-thread analysis instead of serializing after it. Every layer fails open — corrupt, truncated, or version/config-mismatched stores degrade to a fresh computation, never a wrong result — writes are atomic and skipped when clean, and results are byte-identical to an uncached run. Unused-export detection also indexes re-export edges by source module, dropping an O(entry points × edges) scan that dominated the detector on large repos.

  react-doctor points the analysis worker at a per-project summary store next to the existing whole-result dead-code cache, so a changed-files rescan of a large repo re-parses only what changed (sentry, 9k files: ~8.0s → ~3.2s with 0-10 files edited; ~4.0s after adding a file; the cache-fill run costs the same as an uncached scan). The worker also stops running the discarded DRY-pattern redundancy detectors (reportRedundancy: false), which shrinks the summary store by dropping fields only those detectors read, and reports the cache outcome as deadCode.summaryCacheHits / deadCode.summaryCacheMisses in anonymized telemetry (absent whenever no analysis consulted the store). REACT_DOCTOR_NO_CACHE (or the granular REACT_DOCTOR_NO_DEAD_CODE_CACHE) disables it.

• #1054 8c004f0 Thanks @​rayhanadev! - Instant reruns now also work with uncommitted changes: the whole-repo scan-result cache no longer requires a clean worktree — it keys on the exact dirty state (every modified, staged, renamed, deleted, and untracked path plus a hash of its content), so rescanning the same work-in-progress tree hits the cache while any edit still invalidates it.

• #1052 1571119 Thanks @​rayhanadev! - Restore instant reruns on large repos: raise runGit's output cap so the whole-repo scan-result cache works past ~15k tracked files.

  The cache's clean-worktree gates shell out to git through a helper that used Node's default 1 MiB maxBuffer. On repos with roughly 15-25k tracked files (getsentry/sentry: 20,343), git ls-files -v alone exceeds that, execFileSync throws ENOBUFS, the helper swallows it into null, and the gates read null as "hidden tracked state" — so the cache silently never stored or served a scan on exactly the repos where the instant-rerun path saves the most time. The helper now runs with an explicit 64 MiB cap, which clears monorepos with hundreds of thousands of files while still bounding a pathological child process.

• #1058 ea9a775 Thanks @​rayhanadev! - Warm rescans now skip the cross-file lint sidecar for files whose dependencies are unchanged. Previously the per-file lint cache replayed most rules but re-linted EVERY file with the cross-file ruleset (no-barrel-import, the Next.js metadata/Suspense rules, no-mutating-reducer-state, the React Native text rules) on every scan, because a sibling edit can flip an unchanged file's verdict. Each file now carries a dependency fingerprint — the exact set of filesystem probes (resolved import targets, barrel chains, ancestor layouts, nearest package.json/tsconfig, and the negative resolution candidates that catch shadowing) its cross-file rules consulted — and the sidecar replays the stored diagnostics when every probe still answers the same, re-linting only files whose dependency set changed. Every entry fails open (corrupt store, unparseable file, partial lint → fresh re-lint), a cross-file rule without a registered dependency collector re-lints everywhere, and REACT_DOCTOR_NO_CACHE (or the granular REACT_DOCTOR_NO_SIDECAR_CACHE) disables it.

• #1059 bdf8074 Thanks @​rayhanadev! - Added cache-temperature telemetry to the per-scan Sentry wide event, so cache effectiveness is queryable at a glance instead of being inferred from per-subsystem dims. cache.temperature classifies every scan as turbo (whole-repo scan-result replay — now marked by an explicit wholeRepoCacheHit flag on the replay path, never inferred from absent dims), warm (any incremental reuse across the per-file lint, sidecar, or dead-code caches), cold (caches on, zero reuse), or disabled (the global REACT_DOCTOR_NO_CACHE off-switch). cache.warmth is the numeric headline magnitude in [0, 1] — the plain mean of the known subsystem reuse fractions, skipping subsystems that never consulted a cache. The existing per-subsystem dims (lint.cacheHitRatio, lint.sidecarReplayRatio, deadCode.cacheHit, deadCode.summaryCacheHits/Misses) are unchanged. Telemetry-only: no new counters, no JSON-report or cache-schema changes.

• Updated dependencies [ced746f, 20d81f6, ce49250]:

  • deslop-js@0.7.0
  • oxlint-plugin-react-doctor@0.7.0

0.6.3

Patch Changes

• #1045 fc75a3e Thanks @​rayhanadev! - Balance lint batches by file size (LPT) so one oversized batch no longer sets the whole scan's wall clock. The full-scan batcher greedily filled 100-file chunks in discovery order, so a directory of large files (generated modules, vendored bundles, big test fixtures — adjacent in git ls-files order) all landed in ONE batch: on a 619-file corpus with six ~240 KB files that straggler batch ran ~7.5 s while the other six workers finished in ~1 s and idled — and a big enough cluster can trip the 60 s per-batch timeout and drop files. The planner now keeps the same batch count (and therefore the same subprocess count and CPU) but assigns files largest-first to the least-loaded batch, so every batch carries an even share of files and bytes: 2.2× faster wall clock on the skewed corpus (9.7 s → 4.3 s), no measurable change on uniform repos, and diagnostics verified byte-identical on both. Splitting into MORE batches to feed idle workers was measured to regress (each extra concurrent subprocess pays a contended cold start that outweighs its smaller file share) and is deliberately not done. REACT_DOCTOR_LINT_BATCH_ORDERING=arrival rolls back to the old greedy chunking; the previous opt-in cost mode (sort-descending-then-chunk, which concentrated the heavy files instead of spreading them) is superseded by the balanced plan.

• #1046 59e8178 Thanks @​rayhanadev! - Stop lint's pre-spawn setup from starving the overlapped security-scan and supply-chain passes.

... (truncated)

• 160f84c chore: version packages (#1063)
• 6b21b70 feat(core): surface reactDetected so a gated-off scan can't pass for clean (#...
• 574cba6 chore: version packages (#1055)
• ced746f fix(core): make the cache stack survive CI checkouts and the action cache (#1...
• bdf8074 feat(telemetry): classify every scan's cache temperature in the wide event (#...
• ea9a775 perf(core): incremental cross-file sidecar lint via dependency probe traces (...
• ce49250 perf(core): incremental dead-code analysis via a per-file summary cache (#1057)
• 8c004f0 perf(cli): key the scan-result cache on dirty worktree content instead of bai...
• e257a5e perf(core): cache dead-code results so unchanged rescans skip the analysis (#...
• 1571119 fix(cli): raise runGit maxBuffer so the scan cache works on large repos (#1052)
• Additional commits viewable in compare view

Sourced from wrangler's releases.

wrangler@4.108.0

Minor Changes

• #14312 54f74b8 Thanks @​MattieTK! - Delegate agent-driven static Pages deploys to Workers

  When wrangler pages deploy or wrangler pages project create is run by an AI coding agent against a brand-new, purely static project, Wrangler now delegates it to Workers static assets (using autoconfig) instead of Cloudflare Pages. Accounts that already have Cloudflare Pages projects, non-agent (human) sessions, and projects using Pages features that can't be carried across to Workers (Pages Functions, a _worker.js, or a _routes.json file) are unaffected and continue to use Pages. Passing --force to either command opts out of the delegation and deploys to Pages directly. Once the Workers deploy starts it is not silently swapped back to Pages: if it fails, the error is surfaced and the --force opt-out is suggested.

Patch Changes

• #14567 0852346 Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler", "create-cloudflare"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260702.1	1.20260706.1
  @​cloudflare/workers-types	4.20260702.1	5.20260706.1

• #14312 54f74b8 Thanks @​MattieTK! - Avoid silently overwriting an existing Worker during non-interactive deploys that cannot prove they own the name

  A non-interactive deploy (an agent, CI, or the agent-delegated wrangler pages deploy) has no way to prompt before overwriting a Worker, so it now stops if the target name is already taken and this run cannot show it owns that Worker. This applies when there is no Wrangler configuration file naming the Worker and either the name was generated automatically or the deploy is the Pages-to-Workers delegation (where the name carried across is a Pages project name, not proof of Worker ownership). The check reuses the service metadata the deploy already fetches, so it adds no extra API calls.

  Deploys are unaffected when a configuration file names the Worker (so repeat deployments continue to update it), and interactive deploys keep their existing confirmation flow. To update an existing Worker in one of the guarded cases, add a Wrangler configuration file naming it, or deploy under a different name.

• Updated dependencies [0852346]:

  • miniflare@4.20260706.0

wrangler@4.107.1

Patch Changes

• #14514 d88555e Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260701.1	1.20260702.1

• #14564 5fd8bee Thanks @​jibin7jose! - Fix an issue where wrangler dev would not override config vars with values from .dev.vars during local development when the secrets field was defined in the configuration file.

• #14332 5d9990e Thanks @​Divkix! - Fix misleading error guidance when deploying a new Worker with secrets.required

  When a Worker declares secrets.required and has never been deployed before, the previous error message suggested running wrangler secret put <NAME>, which doesn't work because the Worker doesn't exist yet.

  The one path that does work — wrangler deploy --secrets-file <path> — was not mentioned anywhere in the error output.

  The pre-deploy error now explains that wrangler secret put cannot be used for a new Worker, and directs users to the --secrets-file flag instead. The post-deploy error for existing Workers now also mentions --secrets-file alongside wrangler secret put.

• #14507 bf49a41 Thanks @​joey727! - Fix a potential crash when displaying certain CLI output

... (truncated)

• e57b77c Version Packages (#14592)
• 0852346 Bump the workerd-and-workers-types group with 2 updates (#14567)
• 54f74b8 [wrangler] Experiment: redirect agent-driven static Pages deploys to Workers ...
• c5d5e89 Version Packages (#14536)
• 5fd8bee fix(wrangler): override config vars with .dev.vars when secrets is de… (#14564)
• f416dd9 [miniflare] Key local rate limit counters by namespace_id (#14572)
• b973ed3 fix(wrangler): emit an error event for watch-mode rebuild failures (#14561)
• b8439fb [miniflare][wrangler] Fix Windows CI flakes: local-explorer ECONNRESET retry,...
• 1ca8d8f [wrangler] Upgrade signal-exit to v4 for ESM compatibility (#14570)
• 5d9990e [wrangler] Fix first-deploy guidance for required secrets (#14332)
• Additional commits viewable in compare view

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 <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions