ci(renovate): group the xterm bumps, freeze canopy's fork-base pins#281
Merged
Merged
Conversation
The pristine @xterm/addon-webgl in canopy is the UpstreamVsFork regression baseline, deliberately pinned to the exact commit the SDF fork's sdf branch is built from (0.20.0-beta.287 == core 6.1.0-beta.288 == gitHead 8aab3103). Renovate keeps bumping it (e.g. #279), which desyncs the baseline from the fork base and introduces a peer mismatch. Disable it like the other manually-managed pins; it moves in lockstep with the hand-cut fork tarball.
1 task
Deploying mouseterm with
|
| Latest commit: |
ba199f6
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://4979ed2c.mouseterm.pages.dev |
| Branch Preview URL: | https://fix-renovate-pin-xterm-addon.mouseterm.pages.dev |
Two problems showed up in the same Renovate run. The xterm packages arrived as three separate PRs (#277 addon-fit, #278 addon-unicode-graphemes, #280 xterm core). They ship from one repo on one beta counter and each addon peers on the exact core beta it was built against — addon-fit@0.12.0-beta.291 requires ^6.1.0-beta.291, which 6.1.0-beta.288 does not satisfy — so merging any one of them alone lands an unsatisfied peer range and addons compiled against mismatched core internals. Group them, as we already do for storybook, vite, and react-router. The previous commit disabled @xterm/addon-webgl to protect canopy's fork-base pin, but that lockstep is a pair: the SDF tarball bundles core internals, so @xterm/xterm@6.1.0-beta.288 is pinned to the same fork base as @xterm/addon-webgl@0.20.0-beta.287, and nothing was guarding it. #280 happened to leave canopy alone, but only by luck — a bump there would have silently invalidated the UpstreamVsFork baseline, with the tarball URL invisible to Renovate so nothing would flag it. Replace the package-scoped rule with a canopy/package.json-scoped @xterm/** disable, which covers both pins and lets lib and standalone keep tracking upstream. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jul 22, 2026
nedtwigg
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Renovate opened four xterm PRs in one run (#277 #278 #279 #280). Looking at them together surfaced two config gaps.
The lockstep set was split across three PRs.
@xterm/xterm,@xterm/addon-fit, and@xterm/addon-unicode-graphemesship from one repo on one beta counter, and each addon peers on the exact core beta it was built against —addon-fit@0.12.0-beta.291requires^6.1.0-beta.291, which6.1.0-beta.288does not satisfy. Merging any one alone lands an unsatisfied peer range and addons compiled against mismatched core internals; pnpm only warns, so CI stayed green on all three. Now grouped, same as storybook / vite / react-router.canopy's fork lockstep is a pair, and only half of it was guarded. The SDF tarball bundles core internals, so
@xterm/xterm@6.1.0-beta.288is pinned to the same fork base as@xterm/addon-webgl@0.20.0-beta.287(gitHead8aab3103), and nothing protected it. #280 left canopy alone, but by luck rather than policy — a bump there would have silently invalidated theUpstreamVsForkregression baseline, and with the tarball URL invisible to Renovate nothing would have flagged it. The package-scoped@xterm/addon-webgldisable is replaced by acanopy/package.json-scoped@xterm/**disable, covering both pins whilelib/andstandalone/keep tracking upstream.Consequence worth naming: between fork rebases, canopy and lib sit on different
@xterm/xtermbetas. That's expected and confined to the Storybook-only lab — noted indocs/specs/webgl-text.md.Verified with
renovate-config-validatorandpnpm lint:specs. #277, #278, #279 and #280 are closed; Renovate will reopen 288 → 291 as onerenovate/xtermPR once this lands.🤖 Generated with Claude Code