Pin transitive dependencies past their vulnerable ranges via pnpm
overrides, scoped to the affected major so unrelated majors elsewhere
in the tree stay untouched:
- undici 7.24.7 -> 7.28.0 (root/website): @limrun/api pins undici to
an exact version even in its latest release (0.44.0), so bumping the
direct dependency can't fix this; override the transitive resolution
instead.
- shell-quote 1.8.4 -> 1.10.0 (examples/test-app)
- js-yaml 4.1.1 -> 4.3.0 (examples/test-app)
- brace-expansion 5.0.6 -> 5.0.7 (examples/test-app)
- @babel/core 7.29.0 -> 7.29.7 (examples/test-app)
- ws 7.5.10 -> 7.5.13 (examples/test-app)
Resolves all 13 open Dependabot alerts (7 high, 3 moderate, 3 low).
thymikee
added
the
ready-for-human
Summary
Resolves all 13 open Dependabot alerts (7 high, 3 moderate, 3 low) via targeted
pnpm.overridesin the two affected workspace roots (repo root,examples/test-app). No direct dependency bumps were needed to satisfy them — every alert was on a transitive package, and each fix version exists within the currently-used major, so nothing was force-upgraded across a major boundary.Alerts fixed
pnpm-lock.yamlexamples/test-app/pnpm-lock.yamlparse())Tally: 7 high, 3 moderate, 3 low — matches the 13 alerts reported by
gh api .../dependabot/alerts.What changed and why
pnpm-workspace.yaml(root): addedoverrides: { undici@7: ^7.28.0 }.undiciis a transitive dep of@limrun/api(pinned to an exact7.24.7even in@limrun/api's latest release, 0.44.0 — checked all published versions), so bumping the direct dependency can't fix this; the override forces the transitive resolution instead. Scoped to major 7 (via theundici@7selector) so any future undici 8 elsewhere in the tree isn't forced backward. Rootpnpm-lock.yamlregenerated withpnpm install.examples/test-app/pnpm-workspace.yaml: bumped/added overrides forshell-quote,js-yaml,brace-expansion,ws@7, and@babel/core@7, following the existing pattern from fix: resolve test-app dependabot alerts #649 (this app is nested under the repo-root workspace without being a member, so pnpm only honors overrides declared in its ownpnpm-workspace.yaml, notpackage.json). Each override is a caret range scoped to the vulnerable major (js-yaml@4,@babel/core@7,ws@7) so unrelated majors in the tree (e.g.ws@8,brace-expansion@1) stay untouched.examples/test-app/pnpm-lock.yamlregenerated withpnpm install.package.jsonfiles were touched — every fix is a transitive-only override, per the task's preferred fix order.Verification
pnpm audit(root) → "No known vulnerabilities found"pnpm audit(examples/test-app) → "No known vulnerabilities found"pnpm typecheck→ cleanpnpm lint→ cleanpnpm build→ succeeds (pre-existingINEFFECTIVE_DYNAMIC_IMPORTwarnings, unrelated to this change)pnpm test(full unit suite) → 4326 passed, 4 failed on first run, all 4 were timeouts inapp-lifecycle-install.test.ts(Android) andrunner-client.test.ts(Apple) — the repo's known CPU-contention flake in process-spawn tests. Reran both files in isolation:app-lifecycle-install.test.ts13/13 pass,runner-client.test.ts63/63 pass. No assertion failures anywhere.website(pnpm build/ rspress) → builds successfully with the bumpedundici.Not fixed here
Nothing was left unaddressed — all 13 alerts had a patched version available within the currently-used major, so no disruptive major bump or unresolved alert remains.