[alltomatos]

Problem

engines.node in package.json and the runtime support gate published different Node 22 floors, so npm would happily install OmniRoute on a Node version the runtime then rejects.

Source	Node 22 floor
package.json → engines.node	>=22.0.0 <23 || >=24.0.0 <27
src/shared/utils/nodeRuntimeSupport.ts → SUPPORTED_NODE_RANGE	>=22.22.2 <23 || >=24.0.0 <27

README.md published a third phrasing matching the permissive engines value.

Root cause

engines is the only signal npm consults at install time, but SECURE_NODE_LINES (nodeRuntimeSupport.ts) sets the 22 line at 22.22.2 (a deliberate security floor), and SUPPORTED_NODE_RANGE is what the runtime gate enforces. For the gap Node 22.0.0 – 22.22.1, npm install -g omniroute (and npm ci) pass the engine check, then the server refuses to start — the failure surfaces at the least helpful moment, with no hint at install time.

Fix

Make SUPPORTED_NODE_RANGE the single source of truth and align the install-time gate to it (the security floor is the one worth honoring, not the looser one):

• package.json → engines.node → >=22.22.2 <23 || >=24.0.0 <27 (and the mirrored root-package engines in package-lock.json).
• README.md Tech Stack runtime line → >=22.22.2 <23 || >=24.0.0 <27.
• docs/guides/TERMUX_GUIDE.md already published >=22.22.2 … and asserted it "matches engines in package.json / SUPPORTED_NODE_RANGE" — that claim is now actually true (no change needed).

A regression test asserts package.json's engines.node equals SUPPORTED_NODE_RANGE, so the install-time gate and the runtime gate can never drift again. Its natural home — tests/unit/node-runtime-support.test.ts — already imports the constant.

Verification

$ node --import tsx/esm --test tests/unit/node-runtime-support.test.ts
# BEFORE the package.json fix:
not ok 6 - package.json engines.node equals SUPPORTED_NODE_RANGE (install gate == runtime gate)
  expected: '>=22.22.2 <23 || >=24.0.0 <27'
  actual:   '>=22.0.0 <23 || >=24.0.0 <27'
# fail 1

# AFTER the fix:
# tests 6
# pass 6
# fail 0

$ node scripts/check/check-docs-sync.mjs
[docs-sync] PASS - documentation version sync is consistent.

$ npx eslint --suppressions-location config/quality/eslint-suppressions.json tests/unit/node-runtime-support.test.ts
# clean (exit 0)

$ npm run typecheck:core
# clean (exit 0)

Diff summary

• package.json — engines.node floor 22.0.0 → 22.22.2 (Node 22 line).
• package-lock.json — mirror the root-package engines value.
• README.md — Tech Stack runtime range aligned; the repo's lint-staged/Prettier hook also normalized whitespace in two nearby Markdown tables it touched (cosmetic, no content change).
• tests/unit/node-runtime-support.test.ts — add anti-drift regression test.

Closes #7446.

Thanks @diegosouzapw for the precise write-up and pinpointing the exact 22.0.0–22.22.1 gap — it made this a one-line source fix plus a guard.

[gemini-code-assist]

Code Review

This pull request updates the supported Node.js engine range in package.json and README.md from >=22.0.0 <23 || >=24.0.0 <27 to >=22.22.2 <23 || >=24.0.0 <27 to prevent installation on unsupported Node 22 versions (specifically the 22.0.0–22.22.1 gap). It also adds a regression test in tests/unit/node-runtime-support.test.ts to ensure that the engines.node property in package.json remains synchronized with the SUPPORTED_NODE_RANGE constant. There are no review comments to address, and I have no additional feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[diegosouzapw]

Thanks for this — confirmed the drift is real on release/v3.8.49 (engines.node says >=22.0.0, SUPPORTED_NODE_RANGE says >=22.22.2) and your fix (package.json + package-lock.json + README + regression test) is correct and complete for the files it touches.

We have a second PR, #7510, opened a few hours after this one, fixing the exact same package.json/package-lock.json/README.md lines — byte-identical diff on those three files. The only difference is the regression test: yours reads package.json via readFileSync/JSON.parse, which works both under this repo's node --import tsx/esm --test runner and under plain Node. #7510's test uses import packageJson from "../../package.json" assert { type: "json" }, and that assert keyword is a hard SyntaxError under plain Node 22/24 (with { type: "json" } is this repo's established convention — see src/shared/constants/appConfig.ts) — it only passes here because the test loader tolerates the old syntax. We're taking your version as the base and cross-linking #7510 as the duplicate/close-recommended one, crediting both of you for catching this independently.

We'll also fold in two more stale >=22.0.0 references in README.md (the troubleshooting table and the footer badge) that neither PR caught, plus a changelog.d fragment, when we land this.

[diegosouzapw]

Thanks @alltomatos! Merged into release/v3.8.49 — validated in the combined merge-train, all gates green. Great catches (Next16 async params, credential-tuple dedupe).