test: hold type packages at the runtime floor, not the newest release - #281
Merged
Conversation
#262 and #279 are the same defect a day apart. The typescript group swept `@types/vscode` to ^1.125.0 against `engines.vscode: ^1.85.0`, and `@types/node` was proposed at ^26.2.0 against `engines.node: >=22` across all seven manifests. Type packages decide which APIs the compiler accepts, so they have to describe the floor we claim to run on. Point them at the newest release and a call added after that floor typechecks cleanly and throws on the runtime we promised — and the suite will not catch it, because CI runs the floor and the broken call is in whatever path the tests skip. `vsce package` happens to refuse the vscode case, but only minutes into release:check. Nothing at all refuses the node case. The check compares to the precision each ecosystem actually uses. Node's unit is the MAJOR — `^22.10.0` against `>=22` is the intended pin and a minor comparison would fail it, which is exactly what the first draft of this test did. VS Code ships everything as 1.x, so its unit is the MINOR. Manifests are discovered rather than listed, so a new package is covered the day it is added. Verified both directions: re-applying ^26.2.0 fails the seven Node cases, re-applying ^1.125.0 fails the vscode case, and the current tree passes. Dependabot is told to ignore `@types/node` majors, with the reason next to it; minor and patch inside the supported major still flow through the typescript group. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
Closes #279 by making the answer to it mechanical.
Two of the same bug in one day
@types/vscode^1.125.0engines.vscode: ^1.85.0@types/node^26.2.0engines.node: >=22, CI pins Node 22Type packages are not ordinary dependencies — they decide which APIs the compiler will accept, so they have to describe the floor we claim to run on. Point them at the newest release and a call added after that floor typechecks cleanly and then throws on the runtime we promised to support. The suite will not catch it either: CI runs the floor, and the broken call is in whatever path the tests do not execute.
vsce packagehappens to refuse the VS Code case — but only minutes intorelease:check, after a full workspace build. Nothing at all refuses the Node case, which is why #279 was on course to merge green.The check
scripts/types-track-supported-runtime.test.tscompares each type package's floor against the runtime floor it answers to, at the precision that ecosystem actually uses:@types/node@^22.10.0againstengines.node: '>=22'is the intended pin, and a minor-level comparison rejects it. My first draft did exactly that and failed all seven manifests — the test caught my own error before it caught anyone else's.1.x. 1.85 versus 1.125 is the whole question.Manifests are discovered by walking the tree rather than listed, so a package added next month is covered the day it appears — the same reasoning as the install-string scan in #253.
Verified both directions: re-applying
^26.2.0fails the seven Node cases with a message naming the trade-off, re-applying^1.125.0fails the VS Code case, and the current tree passes 8/8.And so it does not come back
.github/dependabot.ymlignores@types/nodemajors only — minor and patch inside the supported major still flow through thetypescriptgroup — with the reason written next to it, alongside the@types/vscodeentry added in #262.Not in scope
Raising
engines.nodeto 26 may well be the right call eventually. It drops every Node between 22 and 26 for everyone installing the CLI, so it is a decision to make on purpose and apply to the engine, the types, CI'snode-version, and the publishedenginesfield together — not something to arrive via a dependency bot.Verification
typecheck, lint, format, docs clean; scripts suite 50 passing.
🤖 Generated with Claude Code