deps(dev)(deps-dev): bump react-doctor from 0.5.5 to 0.5.8 in /SortVision in the react-ecosystem group

[dependabot]

Bumps the react-ecosystem group in /SortVision with 1 update: react-doctor.

Updates react-doctor from 0.5.5 to 0.5.8

Release notes

Sourced from react-doctor's releases.

react-doctor@0.5.8

Patch Changes

• #903 627f9ca Thanks @​rayhanadev! - Bound every long-running scan phase with a hard, runtime-independent timeout so a single wedged dependency socket, quadratic file, or starved event loop can no longer hang a scan for hours (production traces showed runInspect up to 16h and Linter.run up to 7.5h).

  • Binary-split cascade (spawnLintBatches): a cumulative split-time budget (OXLINT_SPLIT_TOTAL_BUDGET_MS, 3 min) and a recursion-depth cap (OXLINT_SPLIT_MAX_DEPTH, 8) now drop the remaining files of a pathological batch into the existing onPartialFailure / skippedCheckReasons["lint:partial"] channel instead of re-waiting a full spawn timeout at every split level.
  • Supply-chain check: a whole-check cap (SUPPLY_CHAIN_TOTAL_TIMEOUT_MS, 90s) fails open (no diagnostics) on a many-socket pileup that ignores the per-fetch abort — the same fail-open contract the per-package lookup already had.
  • Dead-code & lint phases: Effect-level caps (REACT_DOCTOR_DEAD_CODE_PHASE_TIMEOUT_MS, default 2.5 min; REACT_DOCTOR_LINT_PHASE_TIMEOUT_MS, default 5 min) sit above the existing per-unit timeouts and fold a timeout into the existing skipped-check / lint-failure contracts so the rest of the scan still completes. On interruption the dead-code worker and any in-flight oxlint subprocesses are SIGKILL'd (the AbortSignal is threaded down to both), so the cap actually reclaims the work instead of leaving orphaned processes running.
  • Overall deadline: REACT_DOCTOR_SCAN_DEADLINE_MS (default 15 min) backstops any phase not individually capped, raising the new ScanDeadlineExceeded reason on the ReactDoctorError union. It sits above the sum of the per-phase caps so a scan that legitimately uses those budgets degrades gracefully rather than hard-failing.

  All four caps are env-tunable so the budgets can be raised without a redeploy. The defaults sit well above measured p95, so only the pathological tail is affected — no behavior change for normal scans.

• #903 627f9ca Thanks @​rayhanadev! - Run dead-code analysis sequentially by default and scale its timeout to the repo size — fixing a silent drop of all dead-code findings on large supply-chain scans.

  Dead-code (deslop reachability) is CPU-bound, like the oxlint lint pass. Running them concurrently oversubscribed the cores: deslop's parse pool and the oxlint pool each size to all cores, so together they demanded ~2x the cores, thrashed, and the parse pass missed its in-worker timeout. On a large repo (where the pass already runs near the cap) the supply-chain pass bleeding into the dead-code phase was enough to tip it over, and the fail-open path then silently dropped EVERY dead-code finding — observed dropping all ~349 findings on ~2/3 of supply-chain-on Sentry scans, with no user-visible error.

  Dead-code now runs strictly after lint with the full core budget — fastest per-phase and never oversubscribed (overlapping two CPU-bound passes buys no wall-clock anyway). REACT_DOCTOR_DEAD_CODE_OVERLAP=on still forces the overlap, but the two pools now SPLIT the core budget — deslop's parse pool is capped via the new DESLOP_PARSE_CONCURRENCY env and lint shrinks to the remainder — so they sum to the cores instead of doubling them.

  The dead-code phase + in-worker timeouts now scale with the project's source-file count (and inversely with the dead-code core share when overlapped) instead of a flat cap, so a large repo's legitimately-long pass isn't reclaimed before it finishes; the ceiling still reclaims a genuinely wedged worker, and an explicit REACT_DOCTOR_DEAD_CODE_PHASE_TIMEOUT_MS override is honored verbatim. This supersedes the previous memory-gated dead-code overlap and replaces the flat dead-code phase cap with the size-scaled budget.

• #903 627f9ca Thanks @​rayhanadev! - Skip the deslop analysis passes whose output react-doctor discards — an ~8.5x speedup of the dead-code phase on large repos.

  react-doctor consumes only deslop's graph dead-code findings: unused files, unused exports, unused dependencies, and circular dependencies. The dead-code worker projects exactly those four off deslop's result (check-dead-code.ts normalizeResult); the other ~18 fields deslop computes never cross the worker boundary. Two of deslop's passes produce only discarded output and are the bulk of the runtime: the full-TypeScript-Program semantic pass (unused types / enum & class members / misclassified deps), and a set of code-quality detectors (duplicate-block / copy-paste detection, complexity hotspots, feature flags, TypeScript smells, private-type leaks, re-export cycles). Profiling a ~9k-file repo (Sentry) showed generateReport was ~90% of the phase and duplicate-block detection alone was ~83s of ~130s.

  deslop gains a reportCodeQuality flag (default true, so deslop used standalone is unchanged) that gates those six code-quality detectors — they were the only expensive detectors still running unconditionally while the cheaper redundancy detectors were already opt-in. react-doctor's dead-code worker now passes both semantic: { enabled: false } and reportCodeQuality: false.

  Measured on Sentry: deslop drops from ~132s to ~15.5s (8.5x) with byte-identical consumed findings (198 unused files, 10 unused exports, 4 unused deps, 137 cycles), and a full supply-chain-on scan drops from ~142s to ~40s. Skipping these is provably safe — each consumed finding comes from its own detector, independent of the disabled passes — and a parity test locks the invariant so a future deslop change that ever coupled a consumed finding to either pass fails CI first.

• #903 627f9ca Thanks @​rayhanadev! - Diagnostics are now emitted in a deterministic order across runs (JSON report, terminal output, on-disk dump, and the agent handoff), so two runs of the same repo produce byte-identical ordering instead of the parallel lint pass's arrival order. Lint scans also schedule the largest source files first (LPT batch ordering) for better wall-clock on large repos — a free reordering using the file size the minified-file gate already stat'd. Set REACT_DOCTOR_LINT_BATCH_ORDERING=arrival to fall back to discovery order. The diagnostics array content (and the JSON schemaVersion) is unchanged — only the ordering becomes deterministic.

• #906 8b91ac8 Thanks @​rayhanadev! - Fix the GitHub Actions setup flow opening duplicate PRs and bundling unrelated local changes (#904). Before creating a branch, openWorkflowPullRequest now checks for an already-open React Doctor setup PR and surfaces it instead of minting a second timestamped branch, and it bails when the working tree has tracked changes other than the workflow file (which git checkout -b + the whole-index git commit would otherwise sweep into the PR), falling back to staging the workflow file.

• #903 627f9ca Thanks @​rayhanadev! - Memoize the large-minified-file stat/sniff so each source path is statted and content-sniffed at most once per process. A full scan enumerates the source tree more than once — countSourceFiles during discovery, listSourceFiles during the lint pass, and collectSecurityScanFiles during the env-check phase — and every ≥20KB candidate was statSync'd (plus a 64KB content read) on each walk. A module-scope path-keyed cache collapses that to a single stat/sniff per file, wired into the existing clearCaches() invalidation contract so long-running diagnose() consumers still re-read files that change between calls. Behavior is unchanged (identical diagnostics and sourceFileCount); this only removes redundant pre-lint syscalls on full scans.

• #903 627f9ca Thanks @​rayhanadev! - Replace the fixed 16-worker lint ceiling with a memory-and-core-budgeted auto count (up to 32). The auto path now picks min(cores, floor(availableMemory / 1 GiB)) clamped to [1, 32], where availableMemory is os.totalmem() floored by the container's cgroup memory limit (read directly, since Node's memory APIs report the host total inside a container). os.freemem() is deliberately not used — it excludes reclaimable page cache and reads near-zero on macOS / cache-heavy Linux, which would have collapsed the default scan to a single worker.

  The 1 GiB/worker budget matches the per-worker footprint the old fixed-16 ceiling already tolerated (16 workers on a typical 16 GiB CI box), so machines with at least ~1 GiB per core stay core-bound and unchanged. A 32/64-core runner with enough memory now uses up to 32 workers instead of idling cores behind the old 16; a high-core but memory-starved box or container uses fewer workers so the oxlint native binding doesn't OOM (the existing EAGAIN/ENOMEM serial replay remains the runtime backstop). Past ~10 workers parallel efficiency already flattens, so this is headroom and OOM-safety, not a proportional speedup.

  The cgroup v2 limit is read from the mount-root memory.max, which is the container's limit under the standard cgroup-namespace setup CI runners use; a non-namespaced nested cgroup falls back to the host total (with the serial replay as the backstop).

  Note for diagnose({ projects }) batch scans: each project's lint pass is budgeted independently against the whole machine, so a batch (default 4 concurrent projects) can now spawn up to 4 × 32 concurrent oxlint processes on a large runner (was 4 × 16). The per-project EAGAIN/ENOMEM serial replay still backstops any over-subscription; dividing the per-project memory budget by the batch concurrency is a possible follow-up.

  Explicit REACT_DOCTOR_PARALLEL=N and inspect({ concurrency: N }) pins are now clamped to 32 (was 16). The [~N workers] scan suffix can show more than 16 on large runners, and the oxlint.workers telemetry distribution (plus the wide-event workerCount / parallel) now reports the real resolved worker count on the default auto path instead of only when a count was pinned.

• #908 2cadd3f Thanks @​rayhanadev! - Add a once-per-repo migration that pins a mutable @main / @master React Doctor GitHub Action reference in .github/workflows/*.yml to the recommended floating major (@v2).

  An unpinned @main runs whatever the action's HEAD points to with the workflow's write permissions — a supply-chain risk (#299) — and the rewrite also moves the workflow onto the current install- and scan-cached action release. Pinned tags / commit SHAs are deliberate and left untouched, and a different action on @main (e.g. actions/checkout@main) is ignored. Runs once per repo like the legacy-config migration, rewrites only the ref (owner, comments, and the action's version: input are preserved), and logs the change for the user to review and commit (or revert if they intentionally track main).

• #907 7e10716 Thanks @​rayhanadev! - Rework the CLI's per-user state tracking into a small lifecycle framework. All onboarding, growth, and migration state now lives behind one store (cli-state-store.ts) and one set of primitives (cli-lifecycle.ts): gates (fire once per machine or per repo, with an outcome and a version), migrations (run a code/config update once per repo, tracked), and invalidation (bump a gate's/migration's version to re-fire). Onboarding, the CI pitch, the action-upgrade offer, the agent install hint, and the legacy react-doctor.config.json → doctor.config.ts migration are all expressed on it. The on-disk state file upgrades itself in place on first read, preserving every recorded answer — no user is re-prompted. No change to commands, flags, or output.

... (truncated)

Changelog

Sourced from react-doctor's changelog.

0.5.8

Patch Changes

• #903 627f9ca Thanks @​rayhanadev! - Bound every long-running scan phase with a hard, runtime-independent timeout so a single wedged dependency socket, quadratic file, or starved event loop can no longer hang a scan for hours (production traces showed runInspect up to 16h and Linter.run up to 7.5h).

  • Binary-split cascade (spawnLintBatches): a cumulative split-time budget (OXLINT_SPLIT_TOTAL_BUDGET_MS, 3 min) and a recursion-depth cap (OXLINT_SPLIT_MAX_DEPTH, 8) now drop the remaining files of a pathological batch into the existing onPartialFailure / skippedCheckReasons["lint:partial"] channel instead of re-waiting a full spawn timeout at every split level.
  • Supply-chain check: a whole-check cap (SUPPLY_CHAIN_TOTAL_TIMEOUT_MS, 90s) fails open (no diagnostics) on a many-socket pileup that ignores the per-fetch abort — the same fail-open contract the per-package lookup already had.
  • Dead-code & lint phases: Effect-level caps (REACT_DOCTOR_DEAD_CODE_PHASE_TIMEOUT_MS, default 2.5 min; REACT_DOCTOR_LINT_PHASE_TIMEOUT_MS, default 5 min) sit above the existing per-unit timeouts and fold a timeout into the existing skipped-check / lint-failure contracts so the rest of the scan still completes. On interruption the dead-code worker and any in-flight oxlint subprocesses are SIGKILL'd (the AbortSignal is threaded down to both), so the cap actually reclaims the work instead of leaving orphaned processes running.
  • Overall deadline: REACT_DOCTOR_SCAN_DEADLINE_MS (default 15 min) backstops any phase not individually capped, raising the new ScanDeadlineExceeded reason on the ReactDoctorError union. It sits above the sum of the per-phase caps so a scan that legitimately uses those budgets degrades gracefully rather than hard-failing.

  All four caps are env-tunable so the budgets can be raised without a redeploy. The defaults sit well above measured p95, so only the pathological tail is affected — no behavior change for normal scans.

• #903 627f9ca Thanks @​rayhanadev! - Run dead-code analysis sequentially by default and scale its timeout to the repo size — fixing a silent drop of all dead-code findings on large supply-chain scans.

  Dead-code (deslop reachability) is CPU-bound, like the oxlint lint pass. Running them concurrently oversubscribed the cores: deslop's parse pool and the oxlint pool each size to all cores, so together they demanded ~2x the cores, thrashed, and the parse pass missed its in-worker timeout. On a large repo (where the pass already runs near the cap) the supply-chain pass bleeding into the dead-code phase was enough to tip it over, and the fail-open path then silently dropped EVERY dead-code finding — observed dropping all ~349 findings on ~2/3 of supply-chain-on Sentry scans, with no user-visible error.

  Dead-code now runs strictly after lint with the full core budget — fastest per-phase and never oversubscribed (overlapping two CPU-bound passes buys no wall-clock anyway). REACT_DOCTOR_DEAD_CODE_OVERLAP=on still forces the overlap, but the two pools now SPLIT the core budget — deslop's parse pool is capped via the new DESLOP_PARSE_CONCURRENCY env and lint shrinks to the remainder — so they sum to the cores instead of doubling them.

  The dead-code phase + in-worker timeouts now scale with the project's source-file count (and inversely with the dead-code core share when overlapped) instead of a flat cap, so a large repo's legitimately-long pass isn't reclaimed before it finishes; the ceiling still reclaims a genuinely wedged worker, and an explicit REACT_DOCTOR_DEAD_CODE_PHASE_TIMEOUT_MS override is honored verbatim. This supersedes the previous memory-gated dead-code overlap and replaces the flat dead-code phase cap with the size-scaled budget.

• #903 627f9ca Thanks @​rayhanadev! - Skip the deslop analysis passes whose output react-doctor discards — an ~8.5x speedup of the dead-code phase on large repos.

  react-doctor consumes only deslop's graph dead-code findings: unused files, unused exports, unused dependencies, and circular dependencies. The dead-code worker projects exactly those four off deslop's result (check-dead-code.ts normalizeResult); the other ~18 fields deslop computes never cross the worker boundary. Two of deslop's passes produce only discarded output and are the bulk of the runtime: the full-TypeScript-Program semantic pass (unused types / enum & class members / misclassified deps), and a set of code-quality detectors (duplicate-block / copy-paste detection, complexity hotspots, feature flags, TypeScript smells, private-type leaks, re-export cycles). Profiling a ~9k-file repo (Sentry) showed generateReport was ~90% of the phase and duplicate-block detection alone was ~83s of ~130s.

  deslop gains a reportCodeQuality flag (default true, so deslop used standalone is unchanged) that gates those six code-quality detectors — they were the only expensive detectors still running unconditionally while the cheaper redundancy detectors were already opt-in. react-doctor's dead-code worker now passes both semantic: { enabled: false } and reportCodeQuality: false.

  Measured on Sentry: deslop drops from ~132s to ~15.5s (8.5x) with byte-identical consumed findings (198 unused files, 10 unused exports, 4 unused deps, 137 cycles), and a full supply-chain-on scan drops from ~142s to ~40s. Skipping these is provably safe — each consumed finding comes from its own detector, independent of the disabled passes — and a parity test locks the invariant so a future deslop change that ever coupled a consumed finding to either pass fails CI first.

• #903 627f9ca Thanks @​rayhanadev! - Diagnostics are now emitted in a deterministic order across runs (JSON report, terminal output, on-disk dump, and the agent handoff), so two runs of the same repo produce byte-identical ordering instead of the parallel lint pass's arrival order. Lint scans also schedule the largest source files first (LPT batch ordering) for better wall-clock on large repos — a free reordering using the file size the minified-file gate already stat'd. Set REACT_DOCTOR_LINT_BATCH_ORDERING=arrival to fall back to discovery order. The diagnostics array content (and the JSON schemaVersion) is unchanged — only the ordering becomes deterministic.

• #906 8b91ac8 Thanks @​rayhanadev! - Fix the GitHub Actions setup flow opening duplicate PRs and bundling unrelated local changes (#904). Before creating a branch, openWorkflowPullRequest now checks for an already-open React Doctor setup PR and surfaces it instead of minting a second timestamped branch, and it bails when the working tree has tracked changes other than the workflow file (which git checkout -b + the whole-index git commit would otherwise sweep into the PR), falling back to staging the workflow file.

• #903 627f9ca Thanks @​rayhanadev! - Memoize the large-minified-file stat/sniff so each source path is statted and content-sniffed at most once per process. A full scan enumerates the source tree more than once — countSourceFiles during discovery, listSourceFiles during the lint pass, and collectSecurityScanFiles during the env-check phase — and every ≥20KB candidate was statSync'd (plus a 64KB content read) on each walk. A module-scope path-keyed cache collapses that to a single stat/sniff per file, wired into the existing clearCaches() invalidation contract so long-running diagnose() consumers still re-read files that change between calls. Behavior is unchanged (identical diagnostics and sourceFileCount); this only removes redundant pre-lint syscalls on full scans.

• #903 627f9ca Thanks @​rayhanadev! - Replace the fixed 16-worker lint ceiling with a memory-and-core-budgeted auto count (up to 32). The auto path now picks min(cores, floor(availableMemory / 1 GiB)) clamped to [1, 32], where availableMemory is os.totalmem() floored by the container's cgroup memory limit (read directly, since Node's memory APIs report the host total inside a container). os.freemem() is deliberately not used — it excludes reclaimable page cache and reads near-zero on macOS / cache-heavy Linux, which would have collapsed the default scan to a single worker.

  The 1 GiB/worker budget matches the per-worker footprint the old fixed-16 ceiling already tolerated (16 workers on a typical 16 GiB CI box), so machines with at least ~1 GiB per core stay core-bound and unchanged. A 32/64-core runner with enough memory now uses up to 32 workers instead of idling cores behind the old 16; a high-core but memory-starved box or container uses fewer workers so the oxlint native binding doesn't OOM (the existing EAGAIN/ENOMEM serial replay remains the runtime backstop). Past ~10 workers parallel efficiency already flattens, so this is headroom and OOM-safety, not a proportional speedup.

  The cgroup v2 limit is read from the mount-root memory.max, which is the container's limit under the standard cgroup-namespace setup CI runners use; a non-namespaced nested cgroup falls back to the host total (with the serial replay as the backstop).

  Note for diagnose({ projects }) batch scans: each project's lint pass is budgeted independently against the whole machine, so a batch (default 4 concurrent projects) can now spawn up to 4 × 32 concurrent oxlint processes on a large runner (was 4 × 16). The per-project EAGAIN/ENOMEM serial replay still backstops any over-subscription; dividing the per-project memory budget by the batch concurrency is a possible follow-up.

  Explicit REACT_DOCTOR_PARALLEL=N and inspect({ concurrency: N }) pins are now clamped to 32 (was 16). The [~N workers] scan suffix can show more than 16 on large runners, and the oxlint.workers telemetry distribution (plus the wide-event workerCount / parallel) now reports the real resolved worker count on the default auto path instead of only when a count was pinned.

• #908 2cadd3f Thanks @​rayhanadev! - Add a once-per-repo migration that pins a mutable @main / @master React Doctor GitHub Action reference in .github/workflows/*.yml to the recommended floating major (@v2).

  An unpinned @main runs whatever the action's HEAD points to with the workflow's write permissions — a supply-chain risk (#299) — and the rewrite also moves the workflow onto the current install- and scan-cached action release. Pinned tags / commit SHAs are deliberate and left untouched, and a different action on @main (e.g. actions/checkout@main) is ignored. Runs once per repo like the legacy-config migration, rewrites only the ref (owner, comments, and the action's version: input are preserved), and logs the change for the user to review and commit (or revert if they intentionally track main).

• #907 7e10716 Thanks @​rayhanadev! - Rework the CLI's per-user state tracking into a small lifecycle framework. All onboarding, growth, and migration state now lives behind one store (cli-state-store.ts) and one set of primitives (cli-lifecycle.ts): gates (fire once per machine or per repo, with an outcome and a version), migrations (run a code/config update once per repo, tracked), and invalidation (bump a gate's/migration's version to re-fire). Onboarding, the CI pitch, the action-upgrade offer, the agent install hint, and the legacy react-doctor.config.json → doctor.config.ts migration are all expressed on it. The on-disk state file upgrades itself in place on first read, preserving every recorded answer — no user is re-prompted. No change to commands, flags, or output.

... (truncated)

Commits

• f4e8e4b chore: version packages (#891)
• 0b4f4f4 fix(action,core): address Cursor Bugbot findings on the CI-speedup PR (#909)
• 2cadd3f perf(action,core): CI speedups — install cache, persistent scan caches, local...
• 627f9ca perf: speed up large-repo scans + fix dead-code drop under supply-chain (#903)
• 8b91ac8 fix: make GitHub Actions setup flow idempotent and stop bundling local change...
• 7e10716 refactor(cli): unify onboarding/growth state into a lifecycle framework (#907)
• 8bbcca8 chore: vendor deslop-js + deslop-cli into the monorepo (#880)
• 96b5bb4 chore: version packages (#827)
• 869f220 feat(cli): warn before mass-fixing a migration-scale bucket (#884)
• a9d2713 feat(cli): group findings a single fix resolves into one root-cause task (#882)
• 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 <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

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
sortvision	Ready	Preview, Comment	Jun 22, 2026 2:07am

[github-actions]

QA suite report

Metric	Value
Total tests	655
Passed	655
Failed	0
Warnings	0
Pass rate	100.0%
Grade	S+
Duration	4.80s

Result: passed.

View workflow run

QA vs main (last successful CI on base branch)

Baseline: last green Continuous integration on main @ 0042919 (same test:ci suite).

	Base	This PR	Δ passed
Passed	655	655	0
Failed	0	0	—
Total	655	655	—

Fixed (failed on base, passing on this PR)

None

New failures (failed on this PR; were not failing on base)

None

Still failing (failed on base and still failing on this PR)

None

[github-actions]

Dependabot auto-merge

Auto-merge is enabled (squash). GitHub will merge this PR once all required checks and reviews pass.