frontend CI: node-next-test can never pass, and turns master red whenever it runs

[suttondemlong]

The frontend workflow is red on master. The job that fails is node-next-test, not the real test job — Test app passes in the same run. As far as I can tell the job has never been able to pass, so this is a CI configuration problem rather than a broken frontend.

What fails

Run 29792737096, on the merge of #847, all three matrix entries:

npm error code EBADENGINE
npm error engine Unsupported engine
npm error Not compatible with your version of node/npm: flaredown@0.0.0
npm error Required: {"bower":"1.x","node":"14.x","npm":"6.x"}
npm error Actual:   {"npm":"10.8.2","node":"v20.20.2"}

It never reaches npm run test — it dies at npm install.

Why

Two settings combine:

• frontend/.npmrc sets engine-strict=true, which turns an engines mismatch from a warning into a hard error. Added 2021-10-12 in Downgrade Node to work around runtime issue #472.
• frontend/package.json declares "engines": {"bower": "1.x", "node": "14.x", "npm": "6.x"}.

node-next-test runs a matrix of Node 16, 18 and 20. None of them satisfy 14.x, so npm install refuses on every entry.

This is not a regression from #847. The job was added on 2023-08-25 in 52e7d984, "Add CI for next Node versions for fun", and at that commit engines.node was already "12.22.6 || ^14" with engine-strict=true — which Node 16, 18 and 20 do not satisfy either. So no combination of matrix entry and engines value on master has ever worked.

Why it only looks broken sometimes

The job sits behind a paths filter (frontend/**, .github/workflows/**). Most merges to master do not touch those paths, so the job is skipped and the workflow reports success in about 10 seconds. #847 was the first change in a while that did touch them, so the job actually ran, and failed. The same thing happened at #815 in November 2025.

So the badge flips green and red based on whether the job ran, not on whether anything works. That is worth fixing on its own, because it makes the signal meaningless.

Options

1. Make it non-blocking — continue-on-error: true on the job. This matches what it was for; the commit that added it says "for fun", i.e. a forward-compatibility probe, not a gate.
2. Delete it, and reintroduce it as part of an actual Node upgrade.
3. Do the Node upgrade. There is already an unmerged node-upgrade branch (9a8f8754, "bot changes for node 14 to 20") that sets engines to {"node": ">=18.x", "npm": ">=8.x"} along with a large package-lock.json regeneration. That is the real fix, and much the biggest of the three.

Options 1 and 2 stop master being red today; option 3 is the actual goal.

Related: the Node versions named in the repo do not agree

Where	Node
frontend/.tool-versions	14.21.3
frontend/package.json engines	14.x
frontend/Dockerfile	14.21.3-bullseye
frontend.yml Test app job	14
root .tool-versions, README Environment list, CLAUDE.md	12.22.6

The four that the frontend actually uses agree on 14, so local setup is fine —
asdf reads the nearest .tool-versions, which in frontend/ pins 14.21.3. It is
the repo-level documentation that is stale: the root .tool-versions and the
README Environment list still say 12.22.6, which is not the version the frontend
has used since #472. Minor, but worth correcting whenever this area is touched.

Found while looking at the CI badges in #871, which is a separate docs-only problem. Neither is related to #870.

[suttondemlong]

Correction: I originally wrote that the documented native frontend setup hits the same EBADENGINE error, on the basis that the root .tool-versions pins Node 12.22.6. That was wrong, and I have edited it out of the description.

There are three .tool-versions files. backend/.tool-versions is a symlink to the root one, but frontend/.tool-versions is a real file pinning nodejs 14.21.3, and asdf reads the nearest one — so working in frontend/ gives Node 14, which satisfies engines. Local setup is fine.

What is left of that point is only a documentation mismatch: the root .tool-versions and the README Environment list still say 12.22.6, which is not what the frontend uses. Nothing to do with the CI failure above, which stands as described.

[suttondemlong]

#868 already fixes this, and fixes it better than any of the options I listed above — I filed this without noticing that PR was open.

Rather than working around the engine check, #868 removes the cause: engines becomes {"node": ">=18"}, so the EBADENGINE abort stops happening for the matrix and node-next-test can pass on its own merits. It also moves .tool-versions and frontend/.tool-versions to 22.23.2 and switches CI to npm ci.

One piece of evidence that may be worth having on that PR, since "does the app actually run on newer Node" was the open question here. I built the frontend from master on Node 18.20.8 and 22.23.2, with frontend/.npmrc in place and bypassing only the engines check:

default                 npm error code EBADENGINE, install aborts
--engine-strict=false   npm install OK, patch-package OK, bower install OK,
                        ember build OK, 7.6M dist/

Identical on both versions, so the engines declaration really was the only thing failing — which matches the note in #868's README that the build works on 18 and newer but not 16 or older. Caveat: I could not run npm run test in that environment (no browser), so the browser test run on 22/24 is still unverified.

Suggest closing this once #868 merges. Until then the description still matches master.

One thing for whoever merges: #868 and #870 conflict, in .tool-versions and the README Environment list. It is trivial — each side edits different lines of the same two lists, so the resolution is to take one line from each — but it will need doing by hand for whichever lands second.

[suttondemlong]

Closing as superseded — #868 is open and already fixes this at the source. No separate work needed here; the build evidence in the comment above is the only part worth carrying over to that PR.