packages/setup claims Node 18 support, and Node 18 has been end-of-life since 2025-04-30

[vladimirrott]

packages/setup/package.json declares:

"engines": { "node": ">=18" }

and packages/setup/node-preflight.js backs it with MIN_MAJOR = 18, which is what produces the friendly "sysknife-setup needs Node 18 or newer" message instead of a syntax error.

Node 18 reached end-of-life on 2025-04-30, sixteen months ago. Node 20 followed on 2026-04-30. Both numbers come from nodejs/Release.

So the published claim is that npx sysknife-setup supports two runtimes that receive no security fixes. The wizard downloads binaries over the network and verifies them against a SHA-256, which is exactly the kind of code where the runtime's TLS stack and its patch level matter.

What is actually true today

Nothing tests the claim. CI ran the wizard's suite on Node 20 and, after #326, runs it on 24. packages/setup/tests/node-preflight.test.mjs exercises the version-comparison logic in isolation, not the wizard on an old runtime. So >=18 has never been observed to hold; it is an assertion, not a measurement.

The decision

Three options, and they are not equivalent.

1. Raise the floor to 22 (maintenance until 2027-04-30) and say why in the message node-preflight.js prints. Users on 18 or 20 get a clear sentence instead of a subtle failure. This is my preference.
2. Keep >=18 and test it, with a CI matrix that runs packages/setup on the floor as well as on current LTS. Honest, and it costs a job.
3. Keep >=18 untested. Then the number should stop appearing in the docs as a support statement.

Anything but option 3 also wants the published statements updated, and there are
six of them rather than the one this issue first named. Verified 2026-09-09 at
5673d20:

$ grep -rn 'Node 18' --include='*.md' .
docs/quickstart.md:23:**Prerequisites:** Node 18 or newer. On Ubuntu 22.04, `apt install nodejs`
README.md:86:Needs **Node 18 or newer**. On Ubuntu 22.04 `apt install nodejs` gives Node 12,
README.md:430:| **npm** | `npx sysknife-setup` | ... needs Node 18+, no compile |
docs/mcp.md:185:Needs Node 18 or newer (Ubuntu 22.04's apt Node is 12, which is too old). The
apps/sysknife-cli/README.md:40:npx sysknife-setup            # needs Node 18+
docs/introduction.md:124:For prebuilt binaries instead of a build, run `npx sysknife-setup` (Node 18+).

Five of those six predate this issue rather than drifting into it: README.md,
docs/quickstart.md and docs/mcp.md all got their line in aeb4d19
(2026-07-28, #116). My omission when I filed this, not new work.

Scope

• packages/setup/package.json engines.node
• packages/setup/node-preflight.js MIN_MAJOR and the message it composes
• packages/setup/tests/node-preflight.test.mjs
• the six Markdown statements listed above, docs/introduction.md:127 among them (it was :124 in the transcript above; the line moved, the sentence did not)
• A line in docs/release.md if the floor becomes a release-time check

Difficulty

easy as a code change, medium as a decision. The edit reaches eight files, nine if the floor becomes a release-time check. Five of them are documentation, carrying six sentences between them. Picking the number is the part that needs an opinion about who is still on Node 18.

Getting started

CONTRIBUTING.md has the build and test commands. npm test --prefix packages/setup is the suite. No CLA and no copyright waiver. The project is MIT.

Comment here before you start if you want to argue for a different floor. That conversation is the issue.

[vladimirrott]

Maintainer decision, so nobody has to open this and find an argument instead of a task: option 1, raise the floor to 22.

The reasoning is in the body already. >=18 has never been observed to hold, and a wizard that downloads binaries over TLS and checks them against a SHA-256 is the wrong place to advertise support for a runtime receiving no security fixes. Option 2 is defensible but costs a CI job to keep a promise nobody asked for; option 3 is honest only if the number stops appearing in the docs, which is more churn than moving it.

So: MIN_MAJOR = 22, engines.node to >=22, and the preflight message says the floor and why, in one sentence a user can act on.

Tests first

packages/setup/tests/node-preflight.test.mjs already exercises the comparison logic in isolation, which is the right place for this.

1. Assert the floor and its source agree: read engines.node out of package.json and assert it names the same major as MIN_MAJOR. Two numbers in two files drift, and this is the one guard that makes them one fact. Prove it bites by changing one and leaving the other.
2. Assert the boundary in both directions: major 21 refused, major 22 accepted. A test that only checks the refusal passes with the floor set to anything higher.
3. Assert the refusal message names the required version. The whole point of the preflight is a sentence instead of a syntax error, so a message that says "unsupported" and no number is a regression even though the exit code is right.
4. Grep the docs surface for the old claim. docs/introduction.md:124 says "(Node 18+)". If that string can survive a floor change, this issue will recur; a check over the published claim is worth more than the edit itself.

Verify with npm test --prefix packages/setup, then revert MIN_MAJOR alone and confirm the suite goes red naming the mismatch.

Difficulty

easy now that the number is decided. Four files and a test.

[vladimirrott]

Two corrections to my own comment above, from a recount at b2c823e6. Whoever takes this should read these before starting, because one of them is a test I asked for that already exists.

Point 1 of "Tests first" is done and has been since July. I asked for an assertion that engines.node and MIN_MAJOR name the same major. It is already there:

$ grep -n 'MIN_MAJOR\|engines' packages/setup/tests/node-preflight.test.mjs
4: * Ubuntu 22.04's `apt install nodejs` gives Node 12, and `engines` in
36:const { unsupportedMessage, MIN_MAJOR } = require('../node-preflight.js');
69:  assert.equal(MIN_MAJOR, 18);
70:  assert.match(pkg.engines.node, />=\s*18/);

So the guard against those two numbers drifting apart is written. What the change needs is both literals moved to 22 in the same commit, and the pleasant consequence is that you get the "prove it bites" step for free: change one and leave the other, and line 69 or line 70 goes red on its own. Points 2, 3 and 4 are still open and still the work.

docs/introduction.md:124 is :127 now. The sentence is untouched; the file grew above it:

$ grep -rn 'Node 18' --include='*.md' .
README.md:86:Needs **Node 18 or newer**. On Ubuntu 22.04 `apt install nodejs` gives Node 12,
README.md:430:| **npm** | `npx sysknife-setup` | [npmjs.com/package/sysknife-setup](https://www.npmjs.com/package/sysknife-setup) — setup wizard; needs Node 18+, no compile |
docs/mcp.md:185:Needs Node 18 or newer (Ubuntu 22.04's apt Node is 12, which is too old). The
apps/sysknife-cli/README.md:40:npx sysknife-setup            # needs Node 18+
docs/quickstart.md:23:**Prerequisites:** Node 18 or newer. On Ubuntu 22.04, `apt install nodejs`
docs/introduction.md:127:For prebuilt binaries instead of a build, run `npx sysknife-setup` (Node 18+).

Still six statements, still the same six files. I have corrected the Scope bullet in the body and left the dated transcript as it was run.

The decision stands: MIN_MAJOR = 22, engines.node to >=22, and the message names the floor and the reason.

[vladimirrott]

@LunaMeerkats offering you this one. packages/setup still claims Node 18 support and Node 18 went end of life, so the wizard promises an environment nobody should be running.

You are the obvious person: #400, #394 and #312 are all wizard behaviour, and #394 in particular was about the wizard's guidance disagreeing with what happens. This is that, with a version number.

One thing to decide rather than assume: dropping a claim and dropping support are different changes. Say in the PR which one you are making, and if it is the second, the engines field and the setup tests move together with the prose.

Separately, #466 is open and blocked on your #461. I will unblock it the moment that lands and it is yours first if you want it.

[LunaMeerkats]

Thanks @vladimirrott — I am taking this under the disclosed autonomous Codex workflow. I will implement option 1 as an intentional support-floor change, not merely remove an untested claim: move engines.node and MIN_MAJOR together to Node 22, make the refusal explain that older releases are end-of-life, add the 21/22 boundary and message regressions, and update the complete published documentation surface. I will keep it isolated from #461 and run the package tests, claim screen, and current non-Rust gates before publishing.