You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
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.
@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 ¯\_(ツ)_/¯
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.
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 :-)
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.
Activity
bnb commentedon Nov 30, 2022
@targos any thoughts on this? 👀
ljharb commentedon Nov 30, 2022
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 commentedon Nov 30, 2022
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 commentedon Nov 30, 2022
@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 commentedon Nov 30, 2022
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 commentedon Nov 30, 2022
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 commentedon Dec 1, 2022
I'm not really involved in
node-gyp, but I'm a bit confused by this issue. Theenginesfield was updated by @wraithgar in #2601 so I would have thought it was coming with npm 9 in mind.wraithgar commentedon Dec 1, 2022
#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
latestbnb commentedon Dec 8, 2022
my apologies for the ping @targos - I saw you were someone with a high number of commits and I know you 😅
lukekarrys commentedon Dec 9, 2022
I opened two PRs to address this issue:
node-gyp@9release line