build(deps-dev): bump @testing-library/jest-dom from 6.9.1 to 7.0.0

[dependabot]

Bumps @testing-library/jest-dom from 6.9.1 to 7.0.0.

Release notes

Sourced from @​testing-library/jest-dom's releases.

v7.0.0

7.0.0 (2026-07-20)

Features

• add toContainAnyBy* and toContainOneBy* query matchers (1e39089)

BREAKING CHANGES

• @​testing-library/dom is now a required peer dependency. The minimum supported Node.js version is now 22.

Repaired release for testing-library/jest-dom#731

v6.10.0

6.10.0 (2026-07-20)

Features

• add toContainAnyBy* and toContainOneBy* query matchers (#731) (cae44df)

Commits

• 1e39089 feat: add toContainAnyBy* and toContainOneBy* query matchers
• cae44df feat: add toContainAnyBy* and toContainOneBy* query matchers (#731)
• 55c07ce ci: switch release to npm trusted publishing (#726)
• 213256f docs: move toHaveSelection from the deprecated section (#717)
• See full diff in compare view

Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for @​testing-library/jest-dom since your current version.

[cloudflare-workers-and-pages]

Deploying quickadd with    Cloudflare Pages

Latest commit:	885ffbe
Status:	✅  Deploy successful!
Preview URL:	https://2512ebb6.quickadd.pages.dev
Branch Preview URL:	https://dependabot-npm-and-yarn-test.quickadd.pages.dev

View logs

[chhoumann]

Verdict: APPROVE as-is. No code change needed. The only PR in this batch that is clear to merge today.

A major in name; in substance the v6.9.1...v7.0.0 diff is 4 commits touching src/matchers.js (+21/-0), a new src/query-matchers.js, types, README and CI. No existing matcher's source or semantics changed, and types/vitest.d.ts is byte-identical to 6.9.1.

The two real deltas

1. engines.node: >=14 -> >=22
2. A non-optional peer "@testing-library/dom": ">=10 <11" (no peerDependenciesMeta), and dist/vitest.mjs now has a top-level import '@testing-library/dom':

import { expect } from 'vitest';
import { e as extensions } from './matchers-b01dabb1.mjs';
import '@testing-library/dom';   // <- new in 7.0.0, absent from all of 6.9.1's dist

Plus 16 purely additive toContainAnyBy* / toContainOneBy* matchers, which cannot collide with anything here.

Matcher inventory: nothing this repo uses moved

Checked all 33 jest-dom matcher names against src/ and tests/. Exactly two are in use: toBeInTheDocument (12 sites) and toHaveAttribute (11 sites), across 7 test files plus tests/vitest-setup.ts. Neither is deprecated in v7 and neither had its source touched. Zero usage of the deprecated trio (toBeInTheDOM, toBeEmpty, toHaveDescription).

The peer resolves correctly, and I decided NOT to declare it explicitly

@testing-library/dom@10.4.1 is linked into jest-dom's private dir:

node_modules/.pnpm/@testing-library+jest-dom@7.0.0_.../node_modules/@testing-library/dom -> 10.4.1

pnpm install --frozen-lockfile is clean, no peer or engine warnings.

I seriously considered adding "@testing-library/dom": "^10" as an explicit devDependency and rejected it. My initial reasoning ("an unsatisfied peer fails loudly and CI catches it") turned out to be wrong, so it is worth stating what is actually true:

• Total absence of the package is loud (MODULE_NOT_FOUND at setup import). But that requires @testing-library/svelte to drop its dependency on dom entirely.
• The likelier failure, an out-of-range provider (e.g. @testing-library/svelte majors onto dom 11), is silent: pnpm links the out-of-window version, exits 0, and pnpm install --frozen-lockfile (what all three CI jobs run) prints no peer diagnostic at all.

So why still not declare it? Because declaring makes that worse, not better. A root "^10" alongside an out-of-range transitive copy installs with zero warnings while two @testing-library/dom copies coexist. The declaration suppresses the only signal that skew exists, and it becomes the next stale pin when jest-dom 8 wants dom 11.

The honest position: the peer is satisfied deterministically by the lockfile edge 7.0.0(@testing-library/dom@10.4.1) plus --frozen-lockfile. It is re-derived from @testing-library/svelte@5.4.2's hard dependency ("@testing-library/dom": "9.x.x || 10.x.x") even with auto-install-peers off, so .npmrc is not load-bearing here. Drift can only enter when the lockfile is regenerated, which always happens inside a reviewable PR. The residual risk is real but narrow: the review trigger is "a @testing-library/svelte major", not "CI will catch it". Worth remembering next time that dependency moves.

^6 was already poisoned, so this PR is about labelling, not exposure

6.10.0 is published and ships the identical breaking change (same >=10 <11 peer, same node >=22) as a minor. The existing "^6.9.1" specifier already permits it, so any lockfile regeneration could have pulled it in. Declining this PR would not have avoided the change, only left it latent.

engines.node

jest-dom@7 declares node >=22 while package.json says ">=20.18.1". That field is already inaccurate on master (jsdom 29 requires ^20.19.0 || ^22.13.0 || >=24.0.0, which 20.18.1 fails), and nothing enforces it: .npmrc has no engine-strict, there is no .nvmrc or node-version-file, and the reusable release workflows do not check it either. I deliberately left it alone here rather than sneak a contributor-facing policy change into a version bump. See my note on #1600 for why I did not touch it there either.

Minor: the diff is slightly wider than the title

Dependabot's re-resolution also moved postcss 8.5.20 -> 8.5.23 and @codemirror/state 6.5.0 -> 6.6.0 inside the @codemirror/view snapshot. Both dev-only; every @codemirror/* module is in esbuild's external array, so neither can reach main.js.

Full gauntlet (branch rebased onto current master)

pnpm install --frozen-lockfile, tsc -noEmit, eslint ., svelte-check (1149 files, 0 errors), vitest 4463 passed / 37 skipped, pnpm run build.

main.js sha256 is byte-identical to the master baseline (2e2cc4486bf66e2342ca246b108ea19b460d25f3f9875a20b52ccc3c77e8d650). jest-dom is test-only and never imported outside *.test.ts, so no live Obsidian smoke is warranted here; running one would be theatre.

Timing

jest-dom@7.0.0 was published 2026-07-20, so it is outside your min-release-age=7 window. This is the one PR in the batch that is clear to merge right now.

Risk: low. Merge second, after #1598 (see #1600 for the ordering and the lockfile hazard).