Engines setting for npm 10 and beyond

[wraithgar]

Discussion issue for deciding the engines entry in future npm versions.

Recently the setting has been a balance between all currently supported node versions at the time of setting, and features within those major node versions we expect to use in npm in the next year.

We may want to consider being more aggressive with the floor of the range, only including versions of node in which this version of npm is expected to be targeted for a backport.

[wraithgar]

Something to think about with that approach is the npm outdated checker, can we make it smarter about which version of npm to suggest? Either by use of dist-tags or having npm itself evaluate the engines field of npm versions? Even if npm uses engines to determine what version to suggest updating to, a dist-tag could still help folks install the latest version of npm for their node version. Perhaps npm update -g is sufficient. These are things to discuss in the interest of balancing the engines field with user experience.

[ljharb]

Wouldn't making this more aggressive cause users of older but still supported nodes to be unable to update to latest npm while their version of node is still in LTS?

[MylesBorins]

I think that we should drop 14 + 16 in the latest update. Still support 18 + 20. With 16 going EOL in September this seems like a reasonable think to do a bit in advance (we are talking 3 months from now).

For 18 + 20 I'd advocate for supporting whatever the most recent versions at the time we make the engines field, unless there is some sort of ecosystem alignment on what good ranges for 18 + 20 should be. With Semver-Minor Backports it is very difficult to ensure consistency re: Node.js / JS feature support, but we can do best effort.

I think it is very reasonable to ensure that folks are on the latest version of an LTS release that is being supported for an extended period of time.

[wraithgar]

Most of the conflicts have come from 14 and 16 versions, there were a LOT of things added in those two that folks wanted to adopt.

Anecdotally I don't see so much of that w/ 18 or 20.

[lukekarrys]

From an ecosystem standpoint, I think our best engines for compatibility would be either ^16.14 || ^18 || >=20 or ^18 || >=20 if we are dropping Node 16 support.

I don't have strong feelings about dropping Node 16 support early. It doesn't gain us any new syntax I could see us using except Array.findLast and Array.findLastIndex.

One side note I wanted to bring up is that we should not change the engines of our dependencies unless we have a need. Without any new syntax pushing us in that direction, the only thing would be other dependencies such as lru-cache being >=16.14 which is incompatible with us currently.

[wraithgar]

From what I've seen in the wild, ESM stuff was the primary driver of where the floor was in v16 for engines settings. That seems to have calmed down, and our current floor is 16.14. There were only 6 more semver minors after that.

[MylesBorins]

We should pin to a later version of 18. Keep in mind that due to LTS process there are features in later versions of 18 that are not support in the initial release (such as the full ESM implementation)

The lowest level of 18 we should support would be the initial 18 LTS release and completely dropping 16.

[wraithgar]

completely dropping 16

For context, 16 goes EOL in September of this year.

[MylesBorins]

Initial 18 LTS was 18.12.0

Features we wouldn't support if we did lower than 18.12 include

• implement WebAssembly Web API
• add initial CLI runner
• util: add parseArgs module
• update V8 to 10.2.154.2
• add CFRG curves to Web Crypto API (
• esm: add chaining to loaders
• http: add diagnostics channel for http client
• module: add isBuiltIn method
• test_runner: expose describe and it
• add tokens to parseArgs

In 18.13 Additioanl features include

• Introduction of the File API
• Support function mocking on Node.js test runner
• add MIME utilities (this seems potentially useful

In 18.14

• test_runner: add reporters
• buffer: add isAscii method

In 8.16

• Support for single executable
• Replace url parser with Ada
• add Buffer.copyBytesFrom(...)

---

I don't know if there is somewhere we can coordinate with Node.js / node-gyp on this... but it feels like we would significantly benefit from some level of ecosystem coordination here

[wraithgar]

the cli has to have the most restrictive engines, all of its dependents can have less restrictive engines. This was what got us turned around last time w/ node-gyp.

[wraithgar]

module: add isBuiltIn method This would allow us to remove at least one dependency from the cli.

[lukekarrys]

I don't know if there is somewhere we can coordinate with Node.js / node-gyp on this.

We coordinated with node-gyp previously in nodejs/node-gyp#2599 and nodejs/node-gyp#2753. The most difficult part was the timeline of landing those changes together (ref: nodejs/node-gyp#2770 which took a long time to land).

I'm the new lead maintainer of node-gyp so it should be easier now to land those changes on node-gyp.

[MylesBorins]

I think we could just cut off to the lastest minor of both 18 + 20 (and 21+) when we cut the release.

That affords us the most possible range of features and minimizes the risk of dependencies moving to a less restrictive range from under us

[wraithgar]

We typically ignore odd numbered versions and just go >= on the highest even that exists at the time. Our support of odd numbered node.js versions is "yeah if it's gonna be a problem in the next major we should address it"