Problem
@types/node is pinned to the engines support floor on purpose.
ac552d5b chore(deps)!: raise runtime floors states it outright:
@types/node is pinned to the support floor (24) instead of latest so
we cannot accidentally use newer-Node APIs.
Reinforced by package.json (engines.node: ">=24.0.0") and
.github/workflows/multi-runtime.yml, which pins the Node leg to '24'
with the comment "24 deliberately — it is the engines floor we claim
to support."
Dependabot does not know this and re-proposes the major bump on every
release. So far: #334, #336, #374 (all closed), #340 (merged to 26.1.0,
then rolled back by ac552d5b), and now #481 — the fourth reopening of
the same decision. Each round costs a review and a close.
Why the pin is load-bearing
The protection is invisible to every gate we run. On #481, after syncing
bun.lock locally:
bun run typecheck — green
bun test — green, 3544 pass / 0 fail across 296 files
Nothing fails, because nothing can fail: the pin's whole job is to make
newer-Node APIs unrepresentable at compile time. Installing both type
majors side by side and compiling the same file against each shows what
it buys:
import { connect } from 'node:quic';
import { convertProcessSignalToExitCode } from 'node:util';
=== @types/node 24.13.3 ===
error TS2307: Cannot find module 'node:quic' or its corresponding type declarations.
error TS2305: Module '"node:util"' has no exported member 'convertProcessSignalToExitCode'.
=== @types/node 26.1.2 ===
(clean)
@types/node 26 adds whole modules that Node 24 does not have
(ffi.d.ts, quic.d.ts). Under the bump, code using them compiles and
ships, then crashes on the runtime floor we advertise.
Proposal
Add an ignore condition so the decision stops coming back:
ignore:
- dependency-name: "@types/node"
update-types: ["version-update:semver-major"]
Minor and patch updates within the pinned major keep flowing. When the
engines floor is raised deliberately, the pin and this rule move
together, as they did in ac552d5b.
Acceptance sketch
Relates to #481, #817.
Problem
@types/nodeis pinned to theenginessupport floor on purpose.ac552d5b chore(deps)!: raise runtime floorsstates it outright:Reinforced by
package.json(engines.node: ">=24.0.0") and.github/workflows/multi-runtime.yml, which pins the Node leg to'24'with the comment "24 deliberately — it is the
enginesfloor we claimto support."
Dependabot does not know this and re-proposes the major bump on every
release. So far: #334, #336, #374 (all closed), #340 (merged to 26.1.0,
then rolled back by
ac552d5b), and now #481 — the fourth reopening ofthe same decision. Each round costs a review and a close.
Why the pin is load-bearing
The protection is invisible to every gate we run. On #481, after syncing
bun.locklocally:bun run typecheck— greenbun test— green, 3544 pass / 0 fail across 296 filesNothing fails, because nothing can fail: the pin's whole job is to make
newer-Node APIs unrepresentable at compile time. Installing both type
majors side by side and compiling the same file against each shows what
it buys:
@types/node26 adds whole modules that Node 24 does not have(
ffi.d.ts,quic.d.ts). Under the bump, code using them compiles andships, then crashes on the runtime floor we advertise.
Proposal
Add an
ignorecondition so the decision stops coming back:Minor and patch updates within the pinned major keep flowing. When the
enginesfloor is raised deliberately, the pin and this rule movetogether, as they did in
ac552d5b.Acceptance sketch
ignorerule present in.github/dependabot.yml@types/nodemajor PRsRelates to #481, #817.