stabilize to a single minimum NodeJS LTS version for `engines`

[thescientist13]

Type of Change

Enhancement

Summary

Coming out of #1202 / #1372, we opened up the range for NodeJS LTS version to try and accommodate all minimum versions with the least amount of experimental features based on the current compatibility matrix at the time

"engines": {
  "node": "^18.20.5 || ^20.18.3 || >=22.12.0"
}

Per research into opening #1372 , here's a current breakdown of key feature we're using and where they stand in the NodeJS release / API status

Feature	Min. Node Version	Changelog	Notes / Status
import.meta.resolve	18.19.0, 20.6.0	https://nodejs.org/docs/latest-v22.x/api/esm.html#importmetaresolvespecifier	Release Candidate
JSON import attributes	18.20.5, 20.18.3, 22.12.0	https://nodejs.org/docs/latest-v22.x/api/esm.html#json-modules	Stable
New Loader Hooks	20.6.0	https://nodejs.org/docs/latest-v22.x/api/module.html#customization-hooks	Release Candidate
TypeScript	22.6.0	With --experimental-strip-types flag, unflagged in >=23, Node v22.x unflagged backport incoming	Experimental (we should also be able to remove the --experimental-strip-types flag from our init TS template)

Details

Prior to 1.0, would like to go back to a single minimum version, using >= so we don't have to constantly be chasing the LTS release schedule, e.g.

The main items we're waiting on

• Stable import.meta.resolve - currently RC as of 20.18.x
• Stable JSON Import Attributes - [v20.x backport] esm: mark import attributes and JSON module as stable nodejs/node#55961
• Stable loader hooks * - currently RC as of 20.18.x
• Stable unflagged TypeStripping - [v22.x backport] module: unflag --experimental-strip-types nodejs/node#57298

I think eventually we can go to something like this for the engines field

"engines": {
  "node": ">=20.?.0"
}

We should also be able to clean up our test scenarios (consolidate TS tests into standard test suite) as well as swap over to using Amaro, if we can jump right to >=22 (since for now we decided to use sucrase in #1433)

Also, we would want to keep up with Vercel's NodeJS supported versions in our adapter
https://github.com/ProjectEvergreen/greenwood/blob/master/packages/plugin-adapter-vercel/src/types/index.d.ts#L3

Also, coming out of #1519, we could also consider enforcing our ESLint rule for node prefixes to match a NodeJS version.
We should also be able to remove our typescript specific test scripts

---

Some additional APIs that would be nice to get out of NodeJS and we should start tracking on

• fs.cp + w / recursive flag - stable as of 22.x - https://nodejs.org/docs/latest-v22.x/api/fs.html#fspromisescpsrc-dest-options
• fs.glob (still experimental) - https://nodejs.org/docs/latest-v22.x/api/fs.html#fspromisescpsrc-dest-options
  • introduced in v22 (as experimental)
  • stable as of v24! - https://nodejs.org/docs/latest-v24.x/api/fs.html#fspromisesglobpattern-options
  • follow up task (GFI) to swap out glob-promises with fs.glob in the Greenwood code base
• parseArgs for the CLI and init packages - https://nodejs.org/api/util.html#utilparseargsconfig
• styleText - https://nodejs.org/api/util.html#utilstyletextformat-text-options / stylized console logging for development and production builds #1393
• URL Pattern - experimental as of Node 24 - https://nodejs.org/api/url.html#class-urlpattern

[thescientist13]

Should be of note that in #1401 looks like can use >= in our engines field