Update dependency @xterm/addon-webgl to v0.20.0-beta.290

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@xterm/addon-webgl (source)	0.20.0-beta.287 → 0.20.0-beta.290

---

Release Notes

xtermjs/xterm.js (@​xterm/addon-webgl)

v0.20.0-beta.290

Compare Source

v0.20.0-beta.289

Compare Source

v0.20.0-beta.288

Compare Source

---

Configuration

📅 Schedule: (in timezone America/Los_Angeles)

• Branch creation
  • Only on Monday (* * * * 1)
• 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.

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	f2ee1ec
Status:	✅  Deploy successful!
Preview URL:	https://359df115.mouseterm.pages.dev
Branch Preview URL:	https://renovate-xterm-addon-webgl-0.mouseterm.pages.dev

View logs

[dormouse-bot]

This bump should not land — recommend closing.

canopy's @xterm/addon-webgl isn't an ordinary dependency to keep current; it's the UpstreamVsFork regression baseline, deliberately pinned to the exact commit the SDF fork's sdf branch is built from. Both canopy/README.md and docs/specs/webgl-text.md state the invariant: the upstream pin must be the same commit as the fork base — 0.20.0-beta.287 == core 6.1.0-beta.288 == gitHead 8aab3103.

Bumping to 0.20.0-beta.290 breaks that two ways:

• Baseline no longer same-commit. Per this PR's own release notes, beta.290 sits at gitHead 699f5537, not 8aab3103. The fork tarball is still sdf-v0.20.0-sdf288.5 (built against core beta.288), so the UpstreamVsFork story would compare pristine-upstream-beta.290 against a fork built from a different commit — the harness stops isolating the fork's changes, which is its entire purpose. The RENDERER_LABELS comment ("same commit as the fork base") would also become factually wrong.
• Peer mismatch. beta.290 peer-requires @xterm/xterm: ^6.1.0-beta.291, but canopy pins @xterm/xterm at 6.1.0-beta.288, so the baseline would run against an unsupported (older) core.

This pin moves manually, in lockstep with the hand-cut @diffplug/xterm-addon-webgl-sdf tarball, only when the fork rebases. To stop Renovate re-opening this every Monday, I opened #281 (adds a packageRules entry disabling @xterm/addon-webgl, matching the existing dockview-react/node precedents).

Heads-up on the sibling PR: #280 bumps @xterm/xterm 6.1.0-beta.288 → 6.1.0-beta.291. Because canopy shares that pin, merging #280 would desync canopy's core from the same fork tarball for the same lockstep reason. Unlike @xterm/addon-webgl (canopy-only), @xterm/xterm is also used by lib/standalone where a core bump may be wanted, and a packageRules match can't target just the canopy instance — so how to gate that is a maintainer call rather than something I've pinned in #281.