Conversation
Replacement PR for the Dependabot bump in #2768, which moved only the two `@types/vscode` declarations. `engines.vscode` is a third site the bot cannot reach, and the half-move fails twice: the policy guard asserts the two are equal, and `vsce` refuses to package when the types are ahead of the engine. ADR-2562 decided the three sites move together, so this raises the extension's required VS Code from 1.125 to 1.134. Rewrites the still-unreleased changeset from #2563 rather than adding a second one — karasu-vscode is on 0.1.3, so the 1.125 floor it described never shipped, and two "raise the minimum" notes in one release would read as contradictory. The lockfile also converges @exodus/bytes 1.15.0 to 1.15.1 under two orphaned snapshot entries left by the jsdom 29 to 30 bump; 1.15.1 is already the version jsdom 30 resolves on main.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Seven of the eight PRs were adopted, one held. Nothing on the supply side: no new publisher, no transferred repo, no new lifecycle script, and not one package name new to the lock. Both CI failures came from the same shape — a declaration Dependabot cannot reach living in the same repo. #2768 moved `@types/vscode` but not `engines.vscode`; ADR-2562 had already settled that the three sites move together, so it lands through replacement PR #2779, which raises the required VS Code to 1.134. #2769 pulls in oxlint's new React rules, which land in correctness and turn 24 diagnostics fatal under `--deny-warnings` with no config change here; it is held while #2775 fixes the sites, and the ADR records why the fix PR's own CI cannot verify that sweep. Deletes the design doc it was promoted from.
Raising engines.vscode to 1.134 turned the WebView job red with "Unable to install extension ... not compatible with VS Code '1.131.0'". The floor is fine — the extension-host job downloads `version: "stable"` fresh and passed on 1.136.1. What failed is the ExTester cache: it stores the VS Code build downloaded on an earlier run, and `restore-keys` restored a pre-bump 1.131.0 even though the bump changed the key. ADR-2562 reasoned that tracking stable makes "CI verifies at or above the floor" true for free. That holds for `.vscode-test.mjs`, but the ExTester job downloads its own VS Code, so a cached copy can sit below the floor — and it does so exactly on the bump the policy exists to police, where it reads as a broken extension rather than a stale cache. Puts the floor in the cache lineage so a bump starts a fresh one while ordinary runs still hit the cache.
|
Pushed a CI fix — the WebView job's failure was a stale cache, not the floor. The extension-host job passed on the same commit (11 passing): it drives This is a hole in ADR-2562's reasoning worth naming. That ADR argued:
True for The fix puts the floor in the cache lineage (both |
Applying the triage turned up a constraint the analysis had missed.
`extester-bootstrap.mjs` calls `downloadCode("max")`, and `max` resolves
to the highest VS Code the pinned `vscode-extension-tester` declares
support for — 1.131.0 on 8.24.0 — so `engines.vscode` cannot exceed it.
Replacement PR #2779 failed on exactly that and is closed.
Raising the floor therefore needs an ExTester bump, and both candidates
break a policy: 8.25.0 clears cooldown but adds `extract-zip@2.0.1`,
which carries an unpatched high advisory (CVE-2026-56876) that upstream
itself backed away from in 8.26.0; 8.26.0 is clean but one day old.
Deferring to 2026-09-14 breaks neither and costs six days of a type
bump, so #2768 becomes a hold folded into #2782.
Also records that this second constraint on the floor has no machine
check, unlike the equality one.
|
Closing — and correcting my earlier comment on this PR, which misdiagnosed the failure. The cache was not the cause. It follows that ADR-2562's "track stable" reasoning has no hole either: it covers The real constraint, now written down in ADR-2773 and #2782:
Raising the floor to 1.134 therefore needs an ExTester bump first, and neither candidate is takeable today:
So #2768 is now a hold rather than an adopt, folded into #2782: on or after 2026-09-14, when 8.26.0 turns 7 days old, one PR takes ExTester 8.26.0 and the 1.134 floor together. The manifest and changeset edits on this branch are a usable starting point for it. |
The #2768 section stated "判定は採用" in the present tense while the decision table and the section below it record the final 保留 and the closure of #2779. A reader hitting that line first came away thinking @types/vscode had landed. Says it was the initial judgment and points forward to where it changed, and keeps what did not change: the floor is still going to 1.134, via #2782, only later. The #2769 heading had the same shape — it still announced the separate-PR plan that the bump's config requirement made impossible — so it now names the arc instead of the abandoned plan. Found by CodeRabbit on #2773.
* docs(design): triage the 2026-09-08 Dependabot batch Analyze all eight open Dependabot PRs upstream: registry publisher and provenance, install scripts, lock dependency edges, and GitHub advisories. Nothing on the supply side: no new publisher, no transferred repo, no new lifecycle script, and not one package name new to the lock. Two PRs fail CI, both because a declaration Dependabot cannot reach lives in the same repo. #2768 moves `@types/vscode` but not `engines.vscode`, which the policy guard from ADR-2562 was written to catch; the fix is the replacement PR that ADR already settled on. #2769 pulls in oxlint's new React rules, which land in correctness and turn 24 existing sites fatal under `--deny-warnings`; the recommendation is to hold the bump and fix those sites in their own PR rather than bundle or silence them. The other six are clean and recommended for merge as-is, including the jsdom 29 to 30 major whose only breaking change is a Node floor the repo already clears. * docs(design): note that the oxlint fix PR's own CI cannot verify the sweep The hold in the triage doc assumed a fix PR, then the bump. But the fix PR runs oxlint 1.76, which does not carry the new rules, so its green is not evidence the sweep was complete. Records where the verification actually happens (#2769's CI after the rebase), and makes the local 1.80.0 run the acceptance criterion for the fix PR. Also corrects the finding count: 24 diagnostics over 21 unique sites in 17 files, not 24 sites in 12 files. * docs(adr): promote the 2026-09-08 Dependabot triage to ADR-2773 Seven of the eight PRs were adopted, one held. Nothing on the supply side: no new publisher, no transferred repo, no new lifecycle script, and not one package name new to the lock. Both CI failures came from the same shape — a declaration Dependabot cannot reach living in the same repo. #2768 moved `@types/vscode` but not `engines.vscode`; ADR-2562 had already settled that the three sites move together, so it lands through replacement PR #2779, which raises the required VS Code to 1.134. #2769 pulls in oxlint's new React rules, which land in correctness and turn 24 diagnostics fatal under `--deny-warnings` with no config change here; it is held while #2775 fixes the sites, and the ADR records why the fix PR's own CI cannot verify that sweep. Deletes the design doc it was promoted from. * docs(adr): change #2768 from adopt to hold in ADR-2773 Applying the triage turned up a constraint the analysis had missed. `extester-bootstrap.mjs` calls `downloadCode("max")`, and `max` resolves to the highest VS Code the pinned `vscode-extension-tester` declares support for — 1.131.0 on 8.24.0 — so `engines.vscode` cannot exceed it. Replacement PR #2779 failed on exactly that and is closed. Raising the floor therefore needs an ExTester bump, and both candidates break a policy: 8.25.0 clears cooldown but adds `extract-zip@2.0.1`, which carries an unpatched high advisory (CVE-2026-56876) that upstream itself backed away from in 8.26.0; 8.26.0 is clean but one day old. Deferring to 2026-09-14 breaks neither and costs six days of a type bump, so #2768 becomes a hold folded into #2782. Also records that this second constraint on the floor has no machine check, unlike the equality one. * docs(adr): correct the overrides claim in ADR-2773 Both this ADR and ADR-2753 said `pnpm-workspace.yaml`'s `overrides:` is empty, so `ERR_PNPM_LOCKFILE_CONFIG_MISMATCH` could not occur. That check read `package.json`'s `pnpm.overrides`, which pnpm 11 ignores — the source of truth is `pnpm-workspace.yaml`, exactly as `.claude/rules/dependabot.md` warns. It holds 23 floors, five of them touching this batch. Redone properly, every resolved version clears its floor, which matches CI staying green on `--frozen-lockfile`. So the outcome stands and the stated reason does not: it is "the floors were satisfied", not "there are no floors". ADR-2753 carries the same false sentence, and the svgo it merged is on the override list — the "direct dependency with an override" shape the rules call out. Its body stays as written (ADR-2687), so the correction lives here. Found by CodeRabbit on #2773. * docs(adr): correct ADR-2773 for the ADR-2333 precedent it missed The ADR rejected both the replacement-PR route and the config route for #2769 on general grounds, without citing ADR-2333 — which had reached the opposite conclusion three weeks earlier on the 1.61 to 1.76 bump, for the same reason that surfaced here: the fix has to ride in the same commit as the bump. Implementing #2775 made that concrete. oxlint 1.76 rejects the config the fix needs outright ("Rule 'globals' not found in plugin 'react'"), so the test-file override cannot land ahead of the bump and the bump cannot land ahead of the fix. Bundling was not a preference, it was forced. #2769 moves from hold to adopt via replacement PR #2784. Records the process gap too: dependency triage edits no files, so the `paths:` triggers never fire and the past-decision check only ran when start-dev reached the work — after the triage had been written. * docs(adr): mark #2768's adopt as the judgment it started at The #2768 section stated "判定は採用" in the present tense while the decision table and the section below it record the final 保留 and the closure of #2779. A reader hitting that line first came away thinking @types/vscode had landed. Says it was the initial judgment and points forward to where it changed, and keeps what did not change: the floor is still going to 1.134, via #2782, only later. The #2769 heading had the same shape — it still announced the separate-PR plan that the bump's config requirement made impossible — so it now names the arc instead of the abandoned plan. Found by CodeRabbit on #2773.
This branch was successfully deployed
1 participant
Purpose
Replacement PR for #2768. Refs #2773.
Summary
Dependabot's #2768 moved the two
@types/vscodedeclarations but notengines.vscode, which it cannot reach. That half-move fails twice, and neither failure is a surprise:The guard was written for exactly this case — its header says "the natural failure mode is a half-move (…) This guard fails first, in the unit run, naming the file" — and ADR-2562 already settled that the three sites move together, as PR #2563 did for 1.125.
Changes
packages/vscode/package.json—engines.vscodeand@types/vscode→^1.134.0packages/vscode-e2e/package.json—@types/vscode→^1.134.0.changeset/vscode-engines-follow-types.md— restated for the 1.134 floorpnpm-lock.yamlTwo things worth a reviewer's attention
The changeset is rewritten, not added.
vscode-engines-follow-types.mdcame from #2563 and still said "raise the minimum to 1.125".karasu-vscodeis on 0.1.3, so that floor never shipped — both entries would land in the same release and read as contradictory. Rewriting the unreleased entry gives one accurate release note. Say the word if you would rather have a second changeset and leave #2563's record intact.The lockfile carries one change beyond the types bump. Regenerating converges
@exodus/bytes1.15.0 → 1.15.1 under two orphaned snapshot entries (html-encoding-sniffer@6.0.0,whatwg-url@16.0.1) left behind by the jsdom 29 → 30 bump in #2766. 1.15.1 is already what jsdom 30 resolves on main, so this is convergence onto an existing version, not a new package. Verified by diffing the lock's dependency edges rather than the raw file.Verification
pnpm vitest run scripts/ci/vscode-version-policy.test.ts— 4 passed (this is the guard that rejected chore(deps-dev): bump @types/vscode from 1.125.0 to 1.134.0 #2768)pnpm --filter karasu-vscode typecheck— clean against the new API levelpnpm changeset status --since=origin/main—karasu-vscodeat minor1.125references across the repo; the only remaining ones are in ADR-2562's body (historical record, immutable per.claude/rules/adr.md) and an illustrative comment in the guard that deliberately makes the point that the literal version does not matter.Preview URL
n/a — no app change.
Scope filter (new-feature PRs only)
n/a — no user-facing feature beyond the version floor noted above.