fix(deps): clear js-yaml DoS advisory via read-yaml-file override

[lukaso-bot]

What

pnpm audit was reporting 1 moderate — js-yaml quadratic-complexity DoS in merge-key handling (GHSA-h67p-54hq-rp68, patched ≥4.2.0).

The existing js-yaml@4: ^4.2.0 override (from 29e3498, which set out to clear exactly this) only constrains the 4.x line. The advisory was actually firing on js-yaml 3.14.2, pulled transitively:

@changesets/cli → @manypkg/get-packages@1.1.3 → read-yaml-file@1.1.0 → js-yaml 3.14.2

read-yaml-file@1.1.0 requires js-yaml ^3.x and calls the removed safeLoad API, so js-yaml can't simply be forced to 4 underneath it. js-yaml never shipped a patched 3.x — the only fix is ≥4.2.0.

Fix

One pnpm override: read-yaml-file@1 → ^2.1.0.

• read-yaml-file@2.1.0 depends on js-yaml ^4.0.0 (pinned to 4.2.0 by the existing override) → advisory cleared.
• It's still CJS (strip-bom@^4, not the ESM strip-bom@5 of read-yaml-file 3.x), so @manypkg/get-packages@1.1.3 can still require() it.
• pnpm changeset status runs clean — the changesets package-discovery path (the only consumer of this chain) still works.

Verification

• pnpm audit → No known vulnerabilities found (was 1 moderate).
• All js-yaml instances now 4.2.0; all read-yaml-file now 2.1.0.
• Full pre-push gate green: build, typecheck, test, a11y-contrast (chromium), biome, shellcheck, actionlint, gitleaks, publint, osv (no High/Critical).
• Lockfile diff is a net removal (13 insertions / 47 deletions): drops the js-yaml@3.14.2 chain (argparse@1, esprima, sprintf-js, pify@4, strip-bom@3, read-yaml-file@1.1.0); adds read-yaml-file@2.1.0 + strip-bom@4.

Scope

Dev-dependency only. The published git-released package is unaffected → no changeset.

🤖 Generated with Claude Code

[lukaso-bot]

In-house adversarial review (Copilot quota-blocked → no automated review landed)

Reviewed the full diff and independently re-ran the one risk the PR's CI does not cover.

Coverage gap I checked: the 8 PR checks (a11y, osv, gitleaks, shell/workflow lint, test matrix) never invoke the changesets package-discovery path — changesets/action only runs in release.yml on push to main. Swapping read-yaml-file out from under @manypkg/get-packages@1.1.3 is exactly the kind of thing that passes CI and then breaks the Version-Packages PR after merge. So I re-ran it in a clean worktree off this branch (pnpm install --frozen-lockfile):

• pnpm changeset status → exit 0. This drives @manypkg/get-packages → read-yaml-file on pnpm-workspace.yaml; it loads all workspace packages cleanly, so the CJS require() of read-yaml-file@2.1.0 works under @manypkg/get-packages@1.1.3.
• pnpm audit → No known vulnerabilities found (was 1 moderate).
• pnpm why confirms every read-yaml-file resolves to 2.1.0 and every js-yaml to 4.2.0 — no js-yaml@3.x remains.

Diff correctness:

• Override targeting is right: read-yaml-file@1 is a versioned override, so it only rewrites requesters in the 1.x range (@manypkg/get-packages@1.1.3 asks for ^1.1.0) and leaves any 2.x+ consumer untouched. No collateral.
• read-yaml-file@2.1.0 deps are js-yaml ^4.0.0 (pinned to 4.2.0 by the existing override) + strip-bom@4 (still CJS) — no ESM trap from the 3.x line.
• Lockfile change is a net removal (drops the js-yaml@3.14.2 chain: argparse@1, esprima, sprintf-js, pify@4, strip-bom@3); no incidental version bumps.
• Dev-dependency only; published git-released unaffected → no changeset needed (correct).

Verdict: no blocking issues; the residual not-covered-by-CI risk is verified clear. Mergeable. (Posted as a comment, not an Approve — GitHub won't let the PR author self-approve.)