chore(deps-dev): bump @types/vscode from 1.125.0 to 1.134.0 - #2768
dependabot[bot] wants to merge 1 commit into
Conversation
dependabot
Bot
added
dependencies
Dependency Triage:
|
Bumps [@types/vscode](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/vscode) from 1.125.0 to 1.134.0. - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/vscode) --- updated-dependencies: - dependency-name: "@types/vscode" dependency-version: 1.134.0 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
7afe379 to
9338ad0
Compare
|
Closing in favour of #2779, which carries this same bump plus the one declaration Dependabot cannot reach.
Nothing is wrong with the version you picked: 1.134.0 is a normal DefinitelyTyped publish, no install script, and the lock moves nothing but the type package. The judgment is adopt, so no Full analysis of this batch: #2773. |
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
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.
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.
|
Correcting my earlier comment here: this is now a hold, not an adopt-via-replacement. #2779 was the replacement PR, and it failed. The reason is a constraint that was not previously written down anywhere:
Raising the floor therefore needs an ExTester bump, and neither candidate can be taken today: 8.25.0 clears the 7-day cooldown but pulls in Deferring breaks neither policy and costs six days on a type-definition bump, so the work is folded into #2782 for on/after 2026-09-14, when 8.26.0 turns 7 days old. This PR stays closed. The judgment is hold, so no Triage record: #2773. |
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.
1 participant
Bumps @types/vscode from 1.125.0 to 1.134.0.
Commits