chore(deps)(deps-dev): bump happy-dom from 20.8.9 to 20.10.6

[dependabot]

Bumps happy-dom from 20.8.9 to 20.10.6.

Release notes

Sourced from happy-dom's releases.

v20.10.6

👷‍♂️ Patch fixes

• Await NodeJS internal ReadableStream promise during teardown - By @​capricorn86 in task #2217

v20.10.5

👷‍♂️ Patch fixes

• Adds cache to query selector parser - By @​capricorn86 in task #2142
  • The selector parser degraded in performance in v20.6.3 to solve more complex selectors
  • Parsing is still a bit slower, but the cache will hopefully mitigate most of the problem

v20.10.4

👷‍♂️ Patch fixes

• Coerce null qualifiedName to empty string in createDocument - By @​Firer in task #2206

v20.10.3

👷‍♂️ Patch fixes

• Fix "~=" attribute selector matching hyphenated substrings in CSS selectors - By @​mixelburg in task #2194

v20.10.2

👷‍♂️ Patch fixes

• Updates external dependencies - By @​capricorn86 in task #2163

v20.10.0

🎨 Features

• Adds support for setting a canvas adapter for handling the canvas rendering using the browser setting canvasAdapter - By @​RAprogramm and @​capricorn86 in task #241
• Adds new package @​happy-dom/node-canvas-adapter - By @​RAprogramm and @​capricorn86 in task #241
  • @​happy-dom/node-canvas-adapter is a pluggable canvas adapter for Happy DOM using node-canvas.
• Adds support for loading image files when enabling the browser setting enableImageFileLoading - By @​capricorn86 in task #241
• Adds support for loading image data URLs - By @​capricorn86 in task #241
• Adds support for ImageData - By @​capricorn86 in task #241
• Adds support for ImageBitmap - By @​capricorn86 in task #241
• Adds support for Window.createImageBitmap() - By @​capricorn86 in task #241

v20.9.0

🎨 Features

• Adds support for event listener properties on Window (e.g. Window.onkeydown) - By @​capricorn86 in task #2131

Commits

• fed1de2 fix: #2217 Await NodeJS internal ReadableStream promise during teardown (#2...
• 6a9adb5 fix: #2142 Adds cache to query selector parser (#2214)
• 4440f5f fix: #2206 Coerce null qualifiedName to empty string in createDocument (#2207)
• 05e5465 chore: #2208 Updates contribution guidelines (#2211)
• 7103b05 chore: #2208 Updates contribution guidelines (#2210)
• 4c292ef chore: #2208 Updates contribution guidelines (#2209)
• 7e25c97 fix: #2194 Fix ~= attribute selector matching hyphenated substrings (#2205)
• b334a12 fix: #2163 Updates external dependencies (#2188)
• 20f89aa fix: #2180 Try to fix publish workflow (#2181)
• f08c3fa chore: #2177 Update happy-conventional-commit (#2179)
• Additional commits viewable in compare view

Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for happy-dom since your current version.

[dependabot]

Labels

The following labels could not be found: dependencies, npm, security. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

[otReviewAgent]

🟡 Issue: The lockfile now resolves most Vitest/Vite peer sets through @types/node@26.0.0, even though the only manifest change is the packages/node-ui happy-dom bump and the root manifest still declares @types/node as ^22. This creates broad, unrelated dependency churn and makes future lockfile reviews harder; it can also let tooling type-check against a different Node API surface than the repo declares. Please regenerate the lockfile with the existing Node types resolution, or make an explicit manifest change if moving the workspace to Node 26 types is intended.

[otReviewAgent]

🟡 Issue: Keep the lockfile update scoped to the node-ui dependency bump

What's wrong
A package-local DOM test dependency bump is re-resolving Vitest/Vite peer sets across many unrelated workspaces. That makes the lockfile much harder to audit, couples node-ui maintenance to repo-wide type-tooling drift, and leaves future maintainers guessing whether @types/node@26 is intentional or just install noise.

Example
devnet/conviction-lazy-settle only declares vitest, but its lockfile resolution now points at @types/node@26.0.1 even though that package is unrelated to the packages/node-ui happy-dom bump.

Suggested direction
Regenerate the lockfile with the update constrained to packages/node-ui, or restore unrelated peer-resolution churn. If the repo should move to @types/node@26, declare that intentionally in the appropriate manifest instead of letting it appear as incidental lockfile noise.

Confidence note
This assumes the PR intent is the package-local happy-dom bump shown in packages/node-ui/package.json; no manifest change makes the workspace-wide @types/node resolution drift explicit.

For Agents
Review pnpm-lock.yaml importers and snapshots. Preserve the behavior of updating packages/node-ui to happy-dom@20.10.6, but regenerate or edit the lockfile so unrelated workspace importers keep their prior @types/node@22.19.11 peer resolutions. If Node 26 types are intended, make that an explicit root/package manifest change and likely a separate dependency-maintenance PR.

[otReviewAgent]

🟡 Issue: Keep the lockfile update scoped to the dependency being bumped

What's wrong
The lockfile change is much broader than the manifest change: a single happy-dom bump in packages/node-ui causes many unrelated workspace importers to resolve Vitest/Vite through @types/node@26.0.1 while the root package still declares @types/node as ^22. That kind of incidental dependency drift makes dependency reviews noisy and obscures the actual ownership boundary of the change.

Example
A reader auditing this dependency bump now has to separate the intended packages/node-ui happy-dom update from a workspace-wide @types/node peer-resolution churn. If the Node type migration is intentional, it deserves its own manifest change; if not, the lockfile should stay focused on the happy-dom update.

Suggested direction
Regenerate the lockfile in a way that only updates the packages/node-ui happy-dom resolution, or make the @types/node 26 migration explicit in package metadata and split it into a separate dependency-hygiene change.

For Agents
Look at pnpm-lock.yaml peer resolutions for Vitest/Vite and the root package.json @types/node declaration. Preserve the packages/node-ui happy-dom bump, but regenerate or constrain the lockfile so unrelated importers do not drift to @types/node@26.0.1 unless that migration is explicitly declared and reviewed separately.

[otReviewAgent]

🟡 Issue: Lockfile churn upgrades unrelated peer resolutions across the workspace

What's wrong
This PR reads like a one-package test DOM update, but the lockfile now changes dependency-resolution state for many unrelated devnet and package importers. That makes dependency review much harder because future readers cannot tell which peer-resolution changes are intentional, and it leaves the lockfile with extra duplicated vite/vitest/coverage snapshot variants for combinations that are not part of the manifest change. The maintainable structure here is a tight lockfile diff whose blast radius matches the manifest edit.

Example
A devnet importer that did not change now has vitest: 4.0.18(...)(@types/node@26.0.1)(happy-dom@20.8.9...), even though the PR only updates packages/node-ui's happy-dom manifest entry.

Suggested direction
Keep dependency metadata narrowly scoped: rerun the package manager in a way that updates only packages/node-ui's happy-dom resolution, or restore the unrelated @types/node/vite/vitest peer snapshot churn. If the workspace really needs Node type resolution 26, declare that as its own intentional dependency-policy change rather than smuggling it through a patch-level happy-dom bump.

For Agents
Regenerate or edit the lockfile so the diff is scoped to the packages/node-ui happy-dom update and its direct transitive changes. Preserve the intended happy-dom@20.10.6 resolution for node-ui. If @types/node@26.0.1 is intentional, make that a declared dependency/version-policy change in a separate, explicit commit/PR and verify the lockfile no longer contains accidental peer-resolution churn.

[otReviewAgent]

🟡 Issue: Keep the lockfile scoped to the happy-dom update

What's wrong
The manifest change is a narrow node-ui happy-dom bump, but the lockfile has broad peer-resolution churn to @types/node@26.1.0 across Vite/Vitest entries that are not backed by any changed package manifest. That makes the dependency graph harder to review and maintain because unrelated environment or resolver drift is mixed into a focused package update.

Example
A reviewer trying to audit this happy-dom patch now has to separate the intentional happy-dom upgrade from an unrelated workspace-wide @types/node peer-context rewrite. For example, packages/node-ui/package.json does not declare an @types/node change, but pnpm-lock.yaml records Vite/Vitest under @types/node@26.1.0.

Suggested direction
Regenerate the lockfile from a clean workspace using the existing @types/node constraints, or split the Node typings/peer-context upgrade into its own explicit PR. The cleaner structure is a minimal dependency diff where each changed lockfile entry traces back to the manifest change being reviewed.

For Agents
In pnpm-lock.yaml, preserve the packages/node-ui happy-dom 20.10.6 resolution but regenerate or edit the lockfile so unrelated Vite/Vitest peer contexts stay on the existing explicit Node typings version unless this PR is intentionally upgrading Node typings. If the Node typings upgrade is intentional, add the corresponding manifest change and make that a deliberate dependency update. Verify the resulting diff is scoped to node-ui's happy-dom upgrade plus its direct transitive dependencies.

[dependabot]

Dependabot can't resolve your JavaScript dependency files. Because of this, Dependabot cannot update this pull request.

[dependabot]

Dependabot can't resolve your JavaScript dependency files. Because of this, Dependabot cannot update this pull request.

[dependabot]

Dependabot can't resolve your JavaScript dependency files. Because of this, Dependabot cannot update this pull request.

[otReviewAgent]

🟡 Issue: The happy-dom bump lacks validation evidence

What's wrong
This PR changes the DOM implementation used by Vitest for node-ui, but the diff adds no test and the provided review notes say no tests were run. Because happy-dom is the runtime substrate for UI tests, a minor bump can change observable DOM behavior and also the trustworthiness of existing tests.

Example
A node-ui component test that relies on happy-dom behavior for events, layout-related DOM APIs, or resource loading could start passing or failing differently after this bump; without at least running the node-ui Vitest suite, the PR does not show that the test environment still exercises the app the same way.

Suggested direction
Add evidence from the relevant package test run, or add a focused regression test if this dependency bump is intended to fix a specific DOM behavior.

Confidence note
The provided notes say only the unified diff was reviewed and no tests were run, so this is based on missing validation evidence rather than a locally reproduced failure.

For Agents
Look at packages/node-ui test scripts and CI config. Run the relevant node-ui test suite, preferably with coverage if that is the normal gate, and record the command/result in the PR. If the bump targets a specific happy-dom fix, add or point to a regression test that fails on 20.8.9 and passes on 20.10.6.