chore(deps): update dependency jsdom to v30

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
jsdom	^29.0.0 → ^30.0.0

---

Release Notes

jsdom/jsdom (jsdom)

v30.0.1

Compare Source

v30.0.0

Compare Source

---

Configuration

📅 Schedule: (in timezone America/New_York)

• Branch creation
  • "before 9am on Monday"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	54.27%	6429 / 11845
🔵	Statements	54.9%	6924 / 12610
🔵	Functions	45.88%	1560 / 3400
🔵	Branches	47.95%	4421 / 9219

File Coverage

No changed files found.

Generated in workflow #1657 for commit 72ce14a by the Vitest Coverage Report Action

[DavidCockerill]

Approving. Clean major, devDependency only — and CI genuinely exercised it rather than skipping: 281/281 test files passed with jsdom 30.0.1 actually installed, so the DOM suites really ran.

One cross-PR correction in the thread, because it changes the plan: this does not supersede studio#1597. The jsdom>undici override in pnpm-workspace.yaml is untouched here, so the security advisory survives this merge. What it does do is remove the reason #1597 currently fails — merge this first, then rebase #1597 and it should go green.

— Reviewed by DAIvid (Claude Opus 5)

[DavidCockerill]

Non-blocking on this PR, but it changes what to do with #1597. This does not supersede it. jsdom 30.0.1 declares undici: ^8.9.0, but pnpm-workspace.yaml still carries 'jsdom>undici': '^7.28.0' and this PR doesn't touch it — so the lockfile here still resolves jsdom→undici 7.28.0 and CVE-2026-13697 survives the merge. Don't close #1597.

It is, however, the prerequisite that unblocks it. I diffed both published tarballs: jsdom 29.1.1's jsdom-dispatcher.js does require("undici/lib/handler/wrap-handler.js"); jsdom 30.0.1's uses only the public Dispatcher. That removed internal is exactly why #1597's CI fails today.

Suggested order: merge this, rebase #1597 (should go green), and refresh the now-stale comment above the override. Keep #1597's explicit ^8.9.0 — the generic 'undici@>=7.0.0': '^8.0.0' could otherwise clamp jsdom below its own floor.

[kriszyp]

🤖 This PR updates jsdom from 29.1.1 to 30.0.1 and refreshes its transitive dependency graph.
package.json:110 contains the direct major bump; the repo's Node 24.18 runtime satisfies jsdom's new engine floor.
pnpm-lock.yaml:4704 and pnpm-lock.yaml:12465 capture the new package and resolved graph, but the latter still forces jsdom onto undici 7.28.0.
One compatibility issue needs correction before merge: jsdom 30 moved to undici 8 and removed its v7 compatibility adapters.

_{🤖 Reviewed with Codex}

[kriszyp]

Can we remove the jsdom-specific undici 7 override as part of this major bump? jsdom 30 moved its dependency to undici 8 and upstream removed the old WrapHandler/UnwrapHandler compatibility path, but the unchanged jsdom>undici: ^7.28.0 override rewrites that dependency back to 7.28.0, as this snapshot shows. Basic DOM-only tests can still initialize because the mismatch is exercised on resource/XHR/interceptor paths, so a green suite would not make this a supported graph. Please remove the scoped override, update its adjacent comment and the matching AGENTS.md note, and regenerate the lockfile so jsdom resolves undici 8; the broad undici override can remain.

[dawsontoth]

Approving on head 72ce14a2. Local verification with Node 24.18.0, pnpm 11.17.0: pnpm install --frozen-lockfile clean, tsc -b --force 0 errors, vitest run 281/281 test files, 2145 passed | 11 skipped.

Resolving the compatibility concern raised in the Codex review. The point was that jsdom 30 moved to undici 8 and dropped its v7 compatibility adapters, while pnpm-workspace.yaml still forces jsdom>undici: ^7.28.0 — so jsdom 30 would be running against an undici it no longer supports. I checked this directly rather than from the changelog, and it doesn't bite:

• Resolved state on this branch is exactly the mismatch described — jsdom@30.0.1 declares undici ^8.9.0, and the override pins it to undici@7.28.0.
• jsdom 30 contains no reference to undici/lib/handler/wrap-handler.js anywhere under lib/ — that's the internal whose absence breaks jsdom 29 against undici 8, and jsdom 30 no longer reaches for it in either direction.
• new JSDOM('<p>hi</p>') constructs and queries fine against undici 7.28.0.
• The full DOM suite really ran — 281 test files with jsdom 30.0.1 installed, all green.

So the declared-range mismatch is cosmetic here: jsdom 30 doesn't use the undici surface that differs between 7 and 8. It's untidy rather than broken, and it resolves itself when the override is deleted.

On the relationship to #1597 — agreed this doesn't supersede it. The jsdom>undici override is untouched here, so the advisory survives the merge. What changes is that the override becomes deletable: jsdom 30 depends on undici ^8.9.0 natively, so once this lands, dropping the jsdom>undici line entirely lets the existing general 'undici@>=7.0.0': '^8.0.0' override carry jsdom to undici 8 — which is what #1597 was trying to force by hand. Merge this, then delete the override rather than rebasing #1597's edit.

devDependency only, no runtime surface. No unexpected changes in the diff.