Engines.node field behavior when Glitch upgrades Node.js from 16 to 18

Direct answer

Glitch should read the engines.node range in package.json at project start, select a Node.js version that satisfies that range (or the closest available), and surface any mismatch through UI indicators, an environment variable, or a build‑time warning. Treating the field as a hard constraint is optional; an opt‑in lock‑file or flag lets existing projects keep using the platform default while giving developers a way to enforce compatibility.

Confirmed facts about the current behavior

• Glitch provisions the latest default Node.js (currently v18) regardless of any engines.node declaration.
• The actual runtime version is visible only in container logs; there is no UI badge or environment variable that shows it.
• No warning is emitted when the running version falls outside the declared range.

Likely explanation of what could change

If Glitch adds a startup step that evaluates engines.node against the set of Node.js versions it provides, three outcomes are possible:

1. Exact match – Glitch launches the matching version (e.g., v16 when the range is "16").
2. Range satisfied but no exact version – Glitch picks the highest available version that still satisfies the range (e.g., v16.20.0 for ">=16 <18").
3. No satisfying version – Glitch falls back to the default, but now emits a warning.

Steps Glitch could take (minimal viable implementation)

1. Detect – During project boot, parse package.json for engines.node.
2. Select – Choose a Node.js version from the platform’s installed set that satisfies the range; if none, keep the default.
3. Notify –
   • Set an environment variable, e.g., GLITCH_NODE_VERSION, containing the actual version.
   • Show a small badge in the project dashboard (green if within range, red otherwise).
   • Emit a build‑time warning visible in the editor console and logs when a mismatch occurs.
4. Opt‑in enforcement – Introduce a .node-version file or an npm‑style engine-strict flag; when present, Glitch refuses to start if the selected version does not satisfy engines.node.

How developers could verify the behavior today

# In the Glitch terminal
node -v                # shows the runtime version
printenv GLITCH_NODE_VERSION  # would show the variable if Glitch added it
cat package.json | grep engines

If the variable is absent or the badge is missing, the platform is still ignoring engines.node.

Missing diagnostic detail that would affect the recommendation

Does Glitch already support a .node-version file or similar mechanism to pin the Node version? If such a file exists, the recommendation shifts to encouraging its use rather than adding a new opt‑in flag.