chore(deps-dev): bump the dev-dependencies group across 1 directory with 2 updates by dependabot[bot] · Pull Request #5 · longphu25/profile

dependabot · 2026-06-19T10:21:43Z

Bumps the dev-dependencies group with 2 updates in the / directory: @mysten/codegen and react-doctor.

Updates @mysten/codegen from 0.10.6 to 0.11.1

Commits

See full diff in compare view

Updates react-doctor from 0.2.16 to 0.5.8

Release notes

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

…ith 2 updates Bumps the dev-dependencies group with 2 updates in the / directory: [@mysten/codegen](https://github.com/MystenLabs/ts-sdks) and [react-doctor](https://github.com/millionco/react-doctor/tree/HEAD/packages/react-doctor). Updates `@mysten/codegen` from 0.10.6 to 0.11.1 - [Release notes](https://github.com/MystenLabs/ts-sdks/releases) - [Commits](https://github.com/MystenLabs/ts-sdks/commits) Updates `react-doctor` from 0.2.16 to 0.5.8 - [Release notes](https://github.com/millionco/react-doctor/releases) - [Changelog](https://github.com/millionco/react-doctor/blob/main/packages/react-doctor/CHANGELOG.md) - [Commits](https://github.com/millionco/react-doctor/commits/react-doctor@0.5.8/packages/react-doctor) --- updated-dependencies: - dependency-name: "@mysten/codegen" dependency-version: 0.11.1 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-dependencies - dependency-name: react-doctor dependency-version: 0.5.7 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-dependencies ... Signed-off-by: dependabot[bot] <support@github.com>

dependabot Bot added dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code labels Jun 19, 2026

dependabot Bot changed the title ~~chore(deps-dev): bump the dev-dependencies group with 2 updates~~ chore(deps-dev): bump the dev-dependencies group across 1 directory with 2 updates Jun 22, 2026

dependabot Bot force-pushed the dependabot/npm_and_yarn/dev-dependencies-188a0cd649 branch from 32a02ef to 7c38117 Compare June 22, 2026 04:57

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore(deps-dev): bump the dev-dependencies group across 1 directory with 2 updates#5

chore(deps-dev): bump the dev-dependencies group across 1 directory with 2 updates#5
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/dev-dependencies-188a0cd649

dependabot Bot commented on behalf of github Jun 19, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

dependabot Bot commented on behalf of github Jun 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

react-doctor@0.5.8

Patch Changes

0.5.8

Patch Changes

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

dependabot Bot commented on behalf of github Jun 19, 2026 •

edited

Loading