fix: keep @types/node on the runtime this ships for - #26
Merged
Conversation
The bump to 26.2.0 went in green, and green was the problem. engines.node is >=24.18.0 <25 and release.config.json declares major 24, so typings a major ahead accept APIs that do not exist where this ships -- and typecheck cleanly while doing it, because nothing has used one yet. The failure would arrive at runtime, on the version the release config calls supported. Pinned back to 24.13.3, which is the newest on the 24 line and what was there before. Three layers, because the config alone is a request rather than a requirement: Dependabot now ignores major updates for @types/node. Its existing group only batches minor and patch, so majors arrived as individual pull requests and were never covered. A test asserts the typings major equals supportedNode.major, and that engines.node names the same major. A hand-edited bump sails past a Dependabot rule; it does not sail past this. Verified in both directions rather than assumed: @types/node 26 against major 24 is caught, and moving the matrix to 26 alongside it passes. The guard blocks drift, not the upgrade. 246 tests, lint and typecheck clean.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR prevents @types/node from drifting ahead of the Node runtime the workspace targets (Node 24), by pinning typings back to the Node 24 line and adding guardrails so future bumps can’t silently desync from engines.node / release.config.json.
Changes:
- Pin
@types/nodeback to24.13.3and regenerate the lockfile accordingly. - Add a manifest test to ensure
@types/nodemajor matchesrelease.config.json’ssupportedNode.major(and thatengines.nodestays aligned). - Configure Dependabot to ignore major updates for
@types/nodeto avoid accidental major drift.
Reviewed changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tests/package-manifests.spec.ts | Adds a test asserting @types/node major tracks the supported runtime major and checks engines.node alignment. |
| package.json | Pins @types/node back to 24.13.3. |
| pnpm-lock.yaml | Updates lockfile resolution to @types/node@24.13.3 (and associated transitive changes). |
| .github/dependabot.yml | Ignores major updates for @types/node to avoid typings leading the runtime. |
Files not reviewed (1)
- pnpm-lock.yaml: Generated file
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
From review, and the third time in this series that an assertion was weaker than the comment beside it. The check said engines.node "names that same major" while testing only the lower-bound substring, so ">=24.18.0 <26" passed -- a range spanning two majors, reading as though it pinned one. It now matches both bounds against supportedNode.major, so the range must cover that major and no other. Verified against the case raised: ">=24.18.0 <26" is caught, along with an unbounded ">=24.18.0" and a wrong lower major. 246 tests, lint and typecheck clean.
CompleteDotTech
added a commit
to CompleteDotTech/sdk
that referenced
this pull request
Aug 21, 2026
`@types/node` was pinned back to the 24 line in OpenCoven#26 because typings a major ahead of `engines.node` accept APIs that do not exist where this ships, and typecheck cleanly while doing it -- the failure arrives at runtime, on the version `release.config.json` calls supported. The commit message for that change says outright that CI could not have caught it, which is why the pin is asserted rather than merely requested of Dependabot. The scaffolds introduce a second copy of that pin, in `TOOLING_DEPENDENCIES`, and the existing guard reads only the root manifest. So the argument that justified the guard now applies to a file the guard does not cover -- and covers it worse, because a scaffold is compiled by users on their machines rather than by this repository's CI. Nothing here would have noticed the two drifting apart. The scaffold spec's own `toBe('6.0.3')` was no help: it pinned a third literal that has to be hand-edited on every bump, which is exactly what the comment above `EXACT_VERSION` argues against -- a test with an opinion about the old number and none about the invariant. It now checks the shape of the pin, and the value is checked against the root manifest where the rest of that argument already lives.
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
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.
@types/nodewas bumped to26.2.0in #16 and went in green — and green wasthe problem.
Typings a major ahead of the runtime accept APIs that do not exist where this
ships, and typecheck cleanly while doing it, because nothing has used one
yet. The failure would arrive at runtime, on the version the release config
calls supported. CI could not have caught it.
Pinned back to 24.13.3 — the newest on the 24 line, and what was there
before the bump.
Three layers, because config alone is a request
Dependabot ignores major updates for
@types/node. Its existingdevelopment-dependenciesgroup only batches minor and patch, which is exactlywhy a major arrived as its own PR and was never covered by the grouping.
A test asserts the typings major equals
supportedNode.major, and thatengines.nodenames the same major. A hand-edited bump sails past a Dependabotrule; it does not sail past this.
The pin itself is asserted by shape (
EXACT_VERSION), as the others are.Verified in both directions
@types/node26 againstsupportedNode.major24supportedNodeto 26 togetherThe guard blocks drift, not the upgrade. When the support matrix genuinely
moves to Node 26, this test moves with it in the same commit — which is the
point.
Checks
246 tests (up from 240), lint and typecheck clean. Lockfile regenerated and
agrees at
24.13.3.🤖 Generated with Claude Code