[dawsontoth]

⊙ Problem

jsdom 30.1.1 declares undici ^8.10.2, but the tree resolved undici 8.10.0 for jsdom and every other dependent (#1847). The cause is the 'undici@>=7.0.0': '^8.9.0' override in pnpm-workspace.yaml: a pkg@range override replaces each dependent's own declared range, so jsdom's floor became ^8.9.0 and pnpm kept reusing the 8.10.0 already in the lockfile. Nothing warned. It is also a security gap, not only a floor mismatch. 8.10.2 is the release that patches GHSA-vp8m-p9jh-q5pm (high severity, affects undici >=8.10.0 <8.10.2) and ten sibling advisories. undici is dev and CI only here (jsdom in vitest, semantic-release in the release workflow), so none of this ships in the Studio bundle.

❓ Your call: Is it right to keep an override rather than drop it? Dropping it would let jsdom pick its own ^8.10.2, but the other dependents would fall back to their declared ranges: @actions/http-client ^6.23.0, @ai-sdk/provider-utils ^7.29.0, @semantic-release/github ^7.0.0. That splits the tree into three undici copies, two of them on 6.x and 7.x lines whose status for these advisories I have not verified. The override keeps one patched copy. Easy to undo either way.

💡 Solution

Replace the two undici selectors (>=7.0.0 and <6.27.0, both ^8.9.0) with one 'undici@<8.10.2': '^8.10.2' selector in pnpm-workspace.yaml. pnpm applies a pkg@range override to every declared range that overlaps the selector, so this one key lifts every range that can resolve below 8.10.2. It leaves ranges already at or above the floor, jsdom's ^8.10.2 included, on their own declaration. The comment beside it records why 8.10.2 is the floor and why the selector must stay <floor.

pnpm install then resolves one copy, undici 8.11.2, for all four dependents, jsdom included. The pnpm-lock.yaml diff touches undici only: the override block, the one undici package and its snapshot entry, and the four dependents' references to it. No other package moved, and the engines field (node >=22.19.0) is the same as 8.10.0's.

Would Renovate have caught this? No. Its dependency dashboard (#601) lists the overrides with no pending update, because the locked 8.10.0 still satisfies ^8.9.0. lockFileMaintenance is disabled in renovate.json, so nothing ever re-resolved undici inside that range. 8.11.2 came out on 2026-09-24, well past Renovate's 3-day minimumReleaseAge, and the dashboard still shows no undici update. Dependabot has no alert for GHSA-vp8m-p9jh-q5pm on this repo either; I checked the open, dismissed and fixed alerts on 2026-10-11.

⚖️ Alternatives

• Keep the selector pair and raise both floors to ^8.10.2. This PR's first revision did that, and gemini-code-assist found the gap it leaves. A dependent declaring a range in [6.27.0, 7.0.0) matches neither selector. Against pnpm 12.8.2 with fixture packages, ^6.28.0 resolved 6.29.0 under the pair and 8.11.2 under the single selector. >=7.0.0 also rewrites ranges that are already above the floor (jsdom's), and would clamp any future ^9 dependent down to 8.x.
• Pin the floor to the newest release (^8.11.2). Rejected: the floor should record the requirement (jsdom's floor plus the security fix), not whatever is newest today. pnpm resolves to 8.11.2 anyway.
• Drop the override. See the call above.

✅ Verification

• Before: on stage, pnpm-lock.yaml held a single undici@8.10.0, and node_modules/jsdom/package.json (30.1.1) declares "undici": "^8.10.2".
• After: grep "^ undici@" pnpm-lock.yaml shows only undici@8.11.2. Resolving undici/package.json from each dependent's own directory returns 8.11.2 for jsdom 30.1.1 (declares ^8.10.2), @actions/http-client 4.0.1 (^6.23.0), @ai-sdk/provider-utils 5.0.53 (^7.29.0) and @semantic-release/github 12.0.10 (^7.0.0).
• Selector semantics: a scratch workspace on pnpm 12.8.2 installed six tarball fixtures declaring undici ^6.23.0, ^6.28.0, ^7.29.0, ^8.5.0, ~8.10.0 and ^8.10.2. Under the old pair, ^6.28.0 escaped to 6.29.0. Under <8.10.2, all six resolved 8.11.2. ~8.10.0 was lifted too, which confirms pnpm matches by overlap, not subset. With no override, the fixtures split into 6.29.0, 7.30.0, 8.10.2 and 8.11.2.
• Full vitest suite (Node 24.21.0, run by the pre-commit hook on the final commit): 395 files, 3,663 passed, 11 skipped, exit 0. That includes all 138 @vitest-environment jsdom files, with no MODULE_NOT_FOUND or collection errors. tsc -b, oxlint and dprint check all exited 0.
• CI-side consumers: @actions/http-client and @ai-sdk/provider-utils both import cleanly from their own directories against 8.11.2. I did not dry-run semantic-release, because that needs release tokens.
• End-to-end route: the unit suite is the end-to-end route for jsdom. The release workflow's use of @actions/http-client is first exercised on the next release.
• Cross-model review: two rounds. Round 1: codex (graded) found nothing. Gemini raised a major claiming the engines: node >=22.19.0 constraint is new. I rejected it: stage's lockfile shows the same constraint on 8.10.0, and CI reads .nvmrc (24.21.0). Round 2, on the single selector: codex LGTM with no findings. Gemini again flagged the override comment as narrating pnpm; I cut it to the floor's reason and the <floor rule, because that rule is what keeps the next edit from reopening the gap. Cursor Muse suggested fixing AGENTS.md's stale "keep jsdom on undici 7" section, which docs(agents): stop telling agents to keep jsdom on undici 7 #1850 already rewrites. The Harper adjudicator failed both rounds because its Claude OAuth session had expired.

Closes #1847

🤖 Generated with Claude Code

_{🤖 Generated by Claude Code (Anthropic Claude); posted via @dawsontoth.}

Related PRs: #1850 overlaps (its new AGENTS.md pnpm note describes the 8.10.0 state this PR fixes and cites 'undici@>=7.0.0' as the range-key example; whichever lands second should put that in the past tense and recommend a <floor selector)
Complexity: easy

_{Review-Coverage: authored=claude; ran=gemini,codex,cursor-muse; blocked=cursor-composer(no-receipt),domain(auth); declined=cursor-grok,cursor-kimi; rounds=2; full=1 @ bd2517c}

_{Review-Attention: read ~3m (raised: degraded review) @ bd2517c}

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	67.53%	10098 / 14953
🔵	Statements	67.68%	10776 / 15920
🔵	Functions	60.78%	2599 / 4276
🔵	Branches	62.53%	7685 / 12289

File Coverage

No changed files found.

Generated in workflow #2143 for commit bd2517c by the Vitest Coverage Report Action