Current Behavior
Two docs each state the supported Node versions, and both contradict the workflows:
| Source |
Claim |
README.md:19 |
"Make sure you have npm on node@16 and above. The CI workflows checks for in node@16, node@18 and node@20" |
.github/copilot-instructions.md:23 |
"Current CI runs the main checks on Node 20 and 22" |
.github/workflows/node-checks.yml:18 (actual) |
node-version: [22, 24] |
Neither doc names a version the main checks actually run on. node@16 and node@18 have both
been end-of-life for some time, so a new contributor following the README can set up an environment
no workflow covers and hit failures the project never sees.
The rest of the workflows are not aligned with each other either, which is worth settling in the
same pass:
| Workflow |
Node |
node-checks.yml (lint, build, test) |
[22, 24] |
release.yml:64 (publish) |
24 |
test-meshery-integration.yml:25 |
22 |
notify-dependents.yml (4 jobs) |
22 |
package.json has no engines field, so nothing declares the supported range to consumers either.
Expected Behavior
One authoritative statement of the supported Node versions, with everything else pointing at it
rather than restating it.
Suggested fix
- Add an
engines.node field to package.json reflecting what CI actually verifies. That is the
machine-readable source of truth, and it is the only one npm can enforce for consumers.
- Reduce
README.md and .github/copilot-instructions.md to a pointer at engines and
node-checks.yml instead of restating the matrix. Two docs independently restating the same CI
matrix is precisely how this drifted three ways.
- Decide whether the
22 used by test-meshery-integration.yml and notify-dependents.yml should
track the node-checks.yml matrix, or is deliberately pinned - and say which, in a comment.
Context
Surfaced by the documentation step of a local validation pipeline while reviewing an unrelated
permission-keys/type-surface change (see #1749 for the other follow-up from that same review). It
was deliberately left out of that PR to keep it scoped; filing here so the fact does not stay wrong
in three places.
Current Behavior
Two docs each state the supported Node versions, and both contradict the workflows:
README.md:19npmonnode@16and above. The CI workflows checks for innode@16,node@18andnode@20".github/copilot-instructions.md:23.github/workflows/node-checks.yml:18(actual)node-version: [22, 24]Neither doc names a version the main checks actually run on.
node@16andnode@18have bothbeen end-of-life for some time, so a new contributor following the README can set up an environment
no workflow covers and hit failures the project never sees.
The rest of the workflows are not aligned with each other either, which is worth settling in the
same pass:
node-checks.yml(lint, build, test)[22, 24]release.yml:64(publish)24test-meshery-integration.yml:2522notify-dependents.yml(4 jobs)22package.jsonhas noenginesfield, so nothing declares the supported range to consumers either.Expected Behavior
One authoritative statement of the supported Node versions, with everything else pointing at it
rather than restating it.
Suggested fix
engines.nodefield topackage.jsonreflecting what CI actually verifies. That is themachine-readable source of truth, and it is the only one npm can enforce for consumers.
README.mdand.github/copilot-instructions.mdto a pointer atenginesandnode-checks.ymlinstead of restating the matrix. Two docs independently restating the same CImatrix is precisely how this drifted three ways.
22used bytest-meshery-integration.ymlandnotify-dependents.ymlshouldtrack the
node-checks.ymlmatrix, or is deliberately pinned - and say which, in a comment.Context
Surfaced by the documentation step of a local validation pipeline while reviewing an unrelated
permission-keys/type-surface change (see #1749 for the other follow-up from that same review). It
was deliberately left out of that PR to keep it scoped; filing here so the fact does not stay wrong
in three places.