Plans for npm 10 about lts HOT 29 CLOSED

The plan looks solid and I don’t think there would be issue in shipping npm v10 in Node 20. However, I feel that shipping such an update to Node v18 might be too risky for two reasons:

1. Node.js v16 is out of LTS at the end of September
2. Node.js v18 enters maintenance soon after
3. Node.js v20 goes LTS end of October

I don’t think there is much time to iron out possible bugs with thr given timeline.

Lastly, I recommend the npm team to stop treating the LTS release as their target and align their releases to Node.js. We could have avoided this discussion entirely if you released npm v10 in March or April.

from lts.

npm@10 has been released and promoted to latest. I updated my original comment which some changes as to what breaking changes actually landed in npm@10 as well as updating the dates to when those events happened.

The PR to land npm@10 in nodejs/node#main has been opened here and is ready for review: nodejs/node#49423

from lts.

Any reasons why NPM 10 is suddenly included in Node 18? Expected NPM 9. It was a surprise for the CI that installed Node wildcard major 18.x. I thought Node LTS was tied to a major release including NPM. I never faced this problem before. Is this the first case of upgrading major NPM in the same major Node? A special exception? Any notes for migration 9 to 10? I see NPM 10 was merged into Node 18.19. So the last version with NPM 9 is Node 18.18 where we have to stick to the minor version now or test NPM 10.

npm ERR! notsup Required: {"node":"^18","npm":"^9"}
npm ERR! notsup Actual:   {"node":"v18.19.0","npm":"10.2.3"}

from lts.

[email protected] has landed in main (nodejs/node#50531) and should be included in the next Node 20 and 18 releases.

I've been keeping this issue open until Node 18 officially ships with npm 10.

from lts.

Didn't you promise in #825 not to make breaking changes (major update of npm) in minor releases of node? Why is it so important to update npm in node v18?

from lts.

I have opened a PR requesting to backport npm@10 to Node 18 here: nodejs/node#49611. This PR is just to run CI and facilitate discussion, since I expect opening the PR to generate more 👀 from contributors. npm@10 should be landing in Node 20 soon and we can continue to get and respond to user feedback.

We've already triaged and fixed one regression (npm/cli#6760) from npm 9 to 10 and are continuing to monitor new issues coming in for npm 10. At this time we have no new npm P0 or P1 bugs in npm@10.

Based on the list of breaking changes that ended up in npm@10 (2 of the more potentially disruptive changes were dropped from the release), we think it makes sense to land npm@10 in Node 18 before LTS. The smaller set of ubreaking changes means the potential surface area for user disruption is smaller than then the process of updating npm 8 to 9.

Lastly, I recommend the npm team to stop treating the LTS release as their target and align their releases to Node.js. We could have avoided this discussion entirely if you released npm v10 in March or April.

Addressing this point directly, our future plans will take this into account. Going forward we want to align more closely with Node around major versions to make this process much smoother. But we think in the case an exception for npm 10 should be discussed.

from lts.

Thanks for the heads up @placaze. I've added a comment to the release proposal for v20.10.0 asking [email protected] to be included.

from lts.

@theJC I've volunteered to do a Node.js 20 release in February for exactly this reason (to include npm 10.3.0). Our usual policy is that changes should first go out in a current release (i.e. Node.js 21) for two weeks so the exact timing depends on when we get a Node.js 21 release out with that version of npm.

from lts.

from the list of breaking changes I believe this is the most likely to have a potential to be disruptive to the community, if the goal is to land on LTS I would advise the team to be very defensive about expanding that list. It might be worth holding on to the next major which hopefully aligns better with our release calendar.

I agree and this is really the suggestion that moved the needle back to "let's not do this". We were already on the fence on this one and the cost/benefit is not anywhere near the level that we would want on a breaking change.

from lts.

Node.js 18 is already LTS. Do you mean before it enters maintenance?

Yes, that is what I meant and corrected my previous comment.

from lts.

[email protected] has landed in main (nodejs/node#50531) and should be included in the next Node 20 and 18 releases.

[email protected] doesn't seem to be backported into the v20.10.0 release proposal (nodejs/node#50682).

• https://github.com/nodejs/node/blob/v18.x-staging/deps/npm/package.json --> v18.x --> [email protected] right now
• https://github.com/nodejs/node/blob/v20.x-staging/deps/npm/package.json --> v20.x --> [email protected] right now

from lts.

Sorry @richardlau , I didn't indicate, but we are specifically looking for a node 18 release to contain 10.3.0 or higher (Node18 is the only version our company supports at this time) to address the repair of the SIGNAL propagation breakage on that version line.

from lts.

It won't need a manual backport but will need to go out in a Node.js 21 release first.

from lts.

@lukekarrys this may be a case of changes in npm10 versus 9 causing Node.js problems when upgrading in the 18.x line -npm/cli#7272

from lts.

Expand the list of default ignored files obeyed during pack and publish

From the list of breaking changes I believe this is the most likely to have a potential to be disruptive to the community, if the goal is to land on LTS I would advise the team to be very defensive about expanding that list. It might be worth holding on to the next major which hopefully aligns better with our release calendar.

from lts.

It would be best to avoid shipping npm 10 in a release, given that glob now depends on BlueOak-1.0.0 licensed software, which is against the IP policy of the foundation. I've already asked an opinion to the Foundation legal staff.

I'm acting out of caution here.

from lts.

It looks like BlueOak-1.0.0 is very much state-of-the-art permissive license, that is shipped within npm v9 in Node already.
And here is good article about it.

N.B.: Trying a new permissive software license

from lts.

Ref nodejs/node#49625.

from lts.

We've opened a new PR to backport npm@10 to v18: nodejs/node#50030. The npm team considers this PR ready to land in v18 now that [email protected] has shipped with v20.8.0. I will be checking the requested CI runs once they complete to ensure the same coverage as the previous draft PR (nodejs/node#49611).

The latest version [email protected] fixes one more P1 regression we found from npm@9. We've been triaging the same list of issues I linked previously and we have no new npm P0 or P1 bugs in npm@10 currently.

Based on the list of breaking changes that ended up in npm@10 (2 of the more potentially disruptive changes were dropped from the release), we think it makes sense to land npm@10 in Node 18 before LTS maintenance. The smaller set of ubreaking changes means the potential surface area for user disruption is smaller than then the process of updating npm 8 to 9.

I am tagging @nodejs/releasers @mcollina @ruyadorno in this comment since we would like to come to a resolution quickly before the final release of v18 later this month.

from lts.

Based on the list of breaking changes that ended up in npm@10 (2 of the more potentially disruptive changes were dropped from the release), we think it makes sense to land npm@10 in Node 18 before LTS. The smaller set of ubreaking changes means the potential surface area for user disruption is smaller than then the process of updating npm 8 to 9.

Node.js 18 is already LTS. Do you mean before it enters maintenance?

FWIW I'm preparing a Node.js 18 release for Tuesday but I'm intending it to be a revert release to undo the libuv updates in Node.js 18.18.0 -- I will not have time to do a full Node.js 18 release. Node.js 18.17.0, 18.17.1 and 18.18.0 all contained regressions which I would like to sort out before landing anything else in Node.js 18.

from lts.

Now that Node.js v18.18.1 has shipped, do we have a better idea of whether or not we can land this?

from lts.

Hi, very new to this issue, and a bit confused. npm 10 is out now and able to be installed without any pre-release flags. It doesn't come bundled with Node 18 yet, is that why this issue is still open? When should we expect a more formal "announcement" or summary of finalized changes with npm 10? Ref the GitHub blog for npm 9

from lts.

please consider using [email protected] at least because of the current fixed node-gyp issues with Python 3.12 ... see nodejs/node-gyp#2869 ... because this already hits some users (and GitHub has alreayd started to update their runners to Python 3.12 - actions/runner#2972). The same 8also if off topic here) would be cool to see ot too late in node.js 20.

PS: I personally would love a "fix node.js 16 version" with also npm 10, but that might not going to happen because formally EOL ;-) ... it will just be forseeable that isues arise when Python 3.12 spreads on the users systems

from lts.

The main reason in my eyes is that node-gyp had compatibility issues with python 3.12 which means that all node-gyp binary package builds would fail. The fix was in npm 10.2.3 or such ... It seems that the npm team decided to do not do a backporting of inclusion of new node-gyp intp an older npm major version ...

So in fact the issue was really big (and with Node.js 18 being LTS sinsce aprio 2025 thats a long timeframe to risk this. But agreed ... backporting would also have had been an dea, but I assume too late now

from lts.

We are very interested in getting 10.3.0 of npm or higher pulled in, due to the fix/revert that restores SIGTERM/SIGINT signal forwarding to child processes - npm/run-script#188

Any chance guidance can be provided as to what Node release we can get an npm version that comes with that has this fix in place? This issue has significant ramifications on the behavior of our services runtime and allowing Node services launched by npm to honor kubernetes shutdown process and the signals it sends to provide time for draining/etc.

from lts.

Can anyone provide details on how best to provide input/encouragement or learn about the process that would be required to consider getting npm 10.3.0+ be the version distributed in a soonish/upcoming Node 18.X release?

from lts.

It will get into next release of v21, coz it already landed in da main 3 weeks ago, and anyone can pull it up for backport in da v18 in any moment 🤷

from lts.

How do we get the next version of Node 21 (21.6.2) to be bumped to having the 10.3.0 or higher version of npm?

from lts.

Thanks for the ping @mhdawson. I've collected that issue along with a few others (that I don't have links to right now) that are all around network requests and the http agent we use.

As an aside, the original purpose of this issue was tracking inclusion of npm 10 across Node.js versions which has been completed. I'm going to close this now and will track these bugs in npm/cli as they get fixed.

from lts.