[QUESTION] Engines of next major version?

[lukekarrys]

In npm/cli we depend on node-gyp and would like to make sure the next major version is compatible with npm when it comes to engines.node.

Previously, npm used ^12.13 as the lower base and node-gyp used ^12.22 which caused the following issue: npm/cli#4987

npm@9 was recently released (but is not yet tagged latest) with the engines set to ^14.17.0 || ^16.13.0 || >=18.0.0 (see our reasoning here npm/statusboard#519).

Are there plans for a major release soon? If so, has engines.node support been discussed?

[bnb]

@targos any thoughts on this? 👀

[ljharb]

Additionally/separately/related, can v9 lower its bottom threshold to v12.13? That would address npm/cli#5049 (comment) without the npm team having to do a dozen backports.

[cclauss]

Given https://github.com/nodejs/release#release-schedule working to preserve unsupported versions seems like busywork that is encouraging the community to be lazy about performing upgrades that may increase reliability, performance, and security.

[ljharb]

@cclauss the support for a version is irrelevant; there's still a semver violation that's happened, and that needs to be fixed - if node-gyp won't drop its arbitrarily raised support threshold, then npm would be forced to backport almost a dozen packages (thus downgrading them to node-gyp 8). The difference in effort seems pretty clear cut to me ¯\_(ツ)_/¯

[cclauss]

npm/statusboard#519 says that npm is making a breaking change in their next major upgrade. That sounds like a good idea to me. My comment is that node-gyp should make a similar breaking change in its next major release to be in alignment with https://github.com/nodejs/release#release-schedule

Making such breaking changes does not mean that dozens of tools need to be backported. It may however mean that dozens of tools need to be upgraded.

[ljharb]

That's totally fine! My comment is just about a patch for the convenience of me, and the npm team, in v9 to lower the threshold. In v10 you can drop whatever you want :-)

[targos]

I'm not really involved in node-gyp, but I'm a bit confused by this issue. The engines field was updated by @wraithgar in #2601 so I would have thought it was coming with npm 9 in mind.

[wraithgar]

#2601 was made for npm 8 so that it could have a much more deduplicated node_modules tree. This request will do the same for npm 9.

Since this issue was created npm 9 has been tagged as latest

[bnb]

my apologies for the ping @targos - I saw you were someone with a high number of commits and I know you 😅

[lukekarrys]

I opened two PRs to address this issue:

• fix: increase node 12 support to ^12.13 #2771 which can be released on the node-gyp@9 release line
• Sync deps and engines with npm #2770 which would be a major release