build(deps-dev): bump jsdom from 29.1.1 to 30.0.0

[dependabot]

Bumps jsdom from 29.1.1 to 30.0.0.

Release notes

Sourced from jsdom's releases.

v30.0.0

Breaking changes:

• Node.js minimum version raised to ^22.22.2 || ^24.15.0 || >=26.0.0.

Other changes:

• Added CSS.escape() and CSS.supports() functions. (@​asamuzaK)
• Added 'background-position-x' and 'background-position-y' CSS properties. (@​olagokemills)
• Fixed getComputedStyle() to convert length values into pixels. (@​asamuzaK)
• Fixed CSS function serialization, e.g., in the return value of getPropertyValue(). (@​asamuzaK)
• Fixed the type of error thrown by document.evaluate() (@​dokson)

Commits

• 20a01fc 30.0.0
• 8c8e583 Precompute WPT expectation matches
• f32245c Bump Node.js floor and dependencies
• 03ef23b Add background-position longhands
• ded056f Test CSS.escape() with numeric IDs
• d312832 Convert CSS values to pixels for computed styles
• 4e0ee41 Implement CSS.escape() and CSS.supports()
• 05eb709 Fix benchmark:compare script on Windows
• 97c1b90 Fix CSS function value serialization
• 15642ba Add benchmark comparison script
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[cloudflare-workers-and-pages]

Deploying quickadd with    Cloudflare Pages

Latest commit:	bc1c315
Status:	✅  Deploy successful!
Preview URL:	https://c85874e8.quickadd.pages.dev
Branch Preview URL:	https://dependabot-npm-and-yarn-jsdo.quickadd.pages.dev

View logs

[chhoumann]

Verdict: this PR was BROKEN as opened. I pushed a fix (bc1c315). Recommend holding the merge until 2026-08-03.

CI was green on the original commit. It should not have been. Green CI is evidence of nothing here.

The bug: jsdom 30 + the jsdom>undici override silently kills jsdom's network stack

jsdom 29 depends on undici ^7.25.0. jsdom 30 moved to ^8.7.0 and deleted its undici-7 handler-adaptation shim (jsdom f32245cf: "Remove compatibility code that is no longer needed with the new Node and undici floors, including old undici handler adaptation"). jsdom 29's lib/jsdom/browser/resources/jsdom-dispatcher.js deep-imports undici/lib/handler/wrap-handler.js and unwrap-handler.js; jsdom 30's does not.

This repo's pnpm.overrides has "jsdom>undici": "7.28.0". Overrides ignore the dependent's declared range, so this PR as opened force-installed undici 7 underneath a jsdom that requires undici 8. Its lockfile still read undici: 7.28.0 inside the jsdom@30.0.0 snapshot.

It does not throw. It does not warn. It hangs. Measured with a real http.createServer + XHR round-trip:

jsdom	undici	result
30.0.0	8.9.0 (jsdom's own range)	load 200 "hello-from-server"
30.0.0	8.9.0 (forced via override)	load 200 "hello-from-server"
30.0.0	7.28.0 (this PR as opened)	hangs forever, no onerror, no throw, no timeout
29.1.1	7.28.0 (master today)	load 200 "hello-from-server"

Reproduced inside this repo's own vitest jsdom environment, not just in isolation:

# on the unfixed branch
Expected: "load:200:hello-from-server"
Received: "TIMEOUT-hung"          (5.57s)

# on master
Test Files  1 passed (1)           (439ms)

# after the fix
Test Files  1 passed (1)           (580ms)

No test in the 4463-test suite touches jsdom's network path, which is exactly why CI stayed green over a dead subsystem.

The fix: drop the override (bc1c315)

 "overrides": {
-  "obsidian-calendar-ui>svelte": "^5.56.3",
-  "jsdom>undici": "7.28.0"
+  "obsidian-calendar-ui>svelte": "^5.56.3"
 }

Lockfile regenerated; resolves to undici 8.9.0. Total diff: 6 insertions, 8 deletions.

On the house rule "leave undici pinned": I want to be explicit that I considered this a violation of the letter and did it anyway, because the letter is unsatisfiable. Keeping 7.28.0 ships a jsdom whose entire network path hangs. The rule's intent is "do not regress security", and deletion does not:

• The override came from 3e381898 ("patch vulnerable undici and js-yaml") as pure advisory remediation, with no behavioural motive. Its sibling entry "@semantic-release/github>undici" was already deleted in cd0a2d98 without incident.
• Verified against the GitHub advisory API: every undici 8.x advisory is first-patched at <= 8.5.0 (GHSA-38rv-x7px-6hhq, GHSA-vmh5-mc38-953g, GHSA-vxpw-j846-p89q, GHSA-p88m-4jfj-68fv, GHSA-pr7r-676h-xcf6, GHSA-35p6-xmwp-9g52 at 8.5.0; GHSA-hm92-r4w5-c3mj at 8.2.0). jsdom's own ^8.7.0 floor is above all of them.
• So jsdom's declared range now enforces what the pin was added to enforce. pnpm audit reports no undici advisory. An exact override is also a freeze Dependabot cannot update: it was holding undici at 7.28.0 while 7.29.0 already existed.

I chose deletion over relaxing to ">=8.5.0" because a relaxed entry would only restate what jsdom already declares, and would rot the same way.

What I deliberately did NOT do: bump engines.node

jsdom 30 requires ^22.22.2 || ^24.15.0 || >=26.0.0 while package.json says ">=20.18.1", so the field is now more wrong than before. I left it alone:

• Nothing enforces it. No engine-strict in .npmrc, no .nvmrc, no node-version-file; CI hardcodes node-version: 24 with check-latest, and the reusable release workflows do not check engines either. The edit would change the behaviour of exactly nothing.
• It is already wrong on master (jsdom 29 rejects the declared 20.18.1 floor), so this is a pre-existing issue, not one this PR creates.
• Copying one devDependency's three-clause disjunction verbatim re-commits the same rot that produced ">=20.18.1" in the first place. Worth noting that value was itself mechanically derived from undici@7.28.0's own engines in commit 3e381898.

This is your call, not mine to make inside a bot PR. If you want it fixed, the honest options are a single floor matching what CI actually tests (">=24.15.0"), or making the field real with engine-strict=true (a genuine policy change that will hard-fail contributor installs). Either deserves its own commit and rationale.

Recommendation: hold this one until 2026-08-03

jsdom@30.0.0 was published 2026-07-27T07:12:10Z, about 5 hours before Dependabot opened this PR. Your ~/.npmrc sets min-release-age=7, and safe-chain correctly refuses to fetch it (npm pack jsdom@30.0.0 fails with "No matching version found ... with a date before 7/20/2026").

This is a same-day .0.0 major of a test-harness dependency. Nothing is waiting on it: QuickAdd's tests need none of what jsdom 30 adds (CSS.escape, px-resolved computed styles, CSS function serialization). Meanwhile its one undocumented change already broke a subsystem silently. Your own supply-chain policy is saying no, and I do not think six days is worth trading for.

The PR is now correct whenever you choose to merge it; I am recommending timing, not blocking.

Everything else in jsdom 30 is inert here

Checked rather than assumed: git grep getComputedStyle returns nothing in src/ or tests/; no test uses toHaveStyle, getPropertyValue, CSS.escape or document.evaluate. display/visibility/opacity are unchanged between 29 and 30, so testing-library's visibility filtering (153 role/text query sites) is unaffected. The px-conversion fix makes jsdom more Chromium-like, narrowing the gap with real Obsidian rather than widening it.

Gauntlet after the fix

pnpm install --frozen-lockfile, tsc -noEmit, eslint ., svelte-check (0 errors), vitest all passing, pnpm run build, plus the XHR probe above. On the branch rebased onto current master, main.js is byte-identical to the master baseline (2e2cc448...) - jsdom is dev-only, reaches neither the bundle (grep -c jsdom main.js = 0) nor the e2e harness (obsidian-e2e depends only on yaml). No live smoke warranted.

I did not add a regression test for the network path. With the override gone, pnpm enforces jsdom's own ^8.7.0 range, so nothing can force a mismatch back in; a test would guard a hazard that no longer exists.

---

Merge order for the batch (this matters)

Verified with git merge-tree, not assumed:

pair	result
#1598 + #1599	CLEAN (auto-merges!)
#1599 + #1600	CLEAN
#1598 + #1600	CONFLICTS

The dangerous one is #1598 + #1599: GitHub will happily let you land both back to back, producing a pnpm-lock.yaml on master that no pnpm install ever generated. It will not visibly fail; master just carries a machine-merged lockfile until the next non-frozen install rewrites it.

Recommended sequence:

1. ci: bump the actions group with 3 updates #1596 any time (no lockfile).
2. build(deps-dev): bump the dev-dependencies group with 5 updates #1598 first (it clears a HIGH brace-expansion advisory). Wait for green master CI.
3. @dependabot rebase build(deps-dev): bump @testing-library/jest-dom from 6.9.1 to 7.0.0 #1599 (never recreate), wait for its CI, then merge. Wait for green master CI.
4. build: bump the docs-dependencies group in /docs with 2 updates #1597 any time (separate package and lockfile).
5. build(deps-dev): bump jsdom from 29.1.1 to 30.0.0 #1600 LAST, and rebase it by hand: because I pushed a commit here, Dependabot has stopped auto-rebasing this branch, and @dependabot recreate would discard the fix. After rebasing, re-run pnpm install --frozen-lockfile and the suite before merging.

Note that a Dependabot rebase re-resolves rather than replays, so the lockfile that lands is not necessarily the one I gauntleted. If you want certainty, build one local integration branch (master + all three) and run the gauntlet once on the exact final tree.

None of these five cuts a release: the policy is [{"scope":"deps","type":"build","release":"patch"}] and build(deps-dev) does not match scope deps.