Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Engines setting for npm 10 and beyond #640

Closed
wraithgar opened this issue Jan 31, 2023 · 14 comments · Fixed by npm/cli#6674
Closed

Engines setting for npm 10 and beyond #640

wraithgar opened this issue Jan 31, 2023 · 14 comments · Fixed by npm/cli#6674

Comments

@wraithgar
Copy link
Member

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
Copy link
Member Author

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
Copy link

ljharb commented Jan 31, 2023

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
Copy link

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link

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
Copy link
Member Author

wraithgar commented Jul 17, 2023

completely dropping 16

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

@MylesBorins
Copy link

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
Copy link
Member Author

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
Copy link
Member Author

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

@lukekarrys
Copy link
Contributor

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
Copy link

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
Copy link
Member Author

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"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants