Problem
Three different Node versions are in play:
package.json:8-9 — "engines": { "node": ">=22.0.0" }, and the same floor in each package
Dockerfile — FROM node:24-alpine for both the build and the runtime stage
- CI — the reusable Node workflow's default
So the published packages advertise support for Node 22, and nothing in this repo ever builds or tests on Node 22.
Why it matters
The servers are published to npm and installed by users via npx on whatever Node they happen to run. A Node 24-only API reaching the source compiles, ships, passes CI, and breaks for a Node 22 user at runtime — the one configuration nobody exercises. The engines floor is a promise the pipeline does not verify.
Proposed approach
Pick one of two, and make it consistent everywhere:
- Raise the floor:
engines.node >= 24 across the root and all six packages, matching the image and CI. Simplest, but drops Node 22 users on the next publish, so it is a breaking change for them and needs a changelog note.
- Or keep
>= 22 and add a Node 22 leg to the CI test matrix, so the promise is tested.
Either way @types/node and the tsconfig target should line up with the decision.
Acceptance criteria
- The
engines floor, the Docker image tag, and the CI matrix agree.
- If the floor moves, it is called out as a breaking change in the release notes.
Problem
Three different Node versions are in play:
package.json:8-9—"engines": { "node": ">=22.0.0" }, and the same floor in each packageDockerfile—FROM node:24-alpinefor both the build and the runtime stageSo the published packages advertise support for Node 22, and nothing in this repo ever builds or tests on Node 22.
Why it matters
The servers are published to npm and installed by users via
npxon whatever Node they happen to run. A Node 24-only API reaching the source compiles, ships, passes CI, and breaks for a Node 22 user at runtime — the one configuration nobody exercises. Theenginesfloor is a promise the pipeline does not verify.Proposed approach
Pick one of two, and make it consistent everywhere:
engines.node >= 24across the root and all six packages, matching the image and CI. Simplest, but drops Node 22 users on the next publish, so it is a breaking change for them and needs a changelog note.>= 22and add a Node 22 leg to the CI test matrix, so the promise is tested.Either way
@types/nodeand thetsconfigtarget should line up with the decision.Acceptance criteria
enginesfloor, the Docker image tag, and the CI matrix agree.