Stop updating npm with breaking update in LTS

[sonnyp]

I hope this is the right place to report this. I supposed this may have been discussed in the past, but I can't find anything.

The deployment of our monorepo on render.com stopped working because Node.js 18 LTS upgraded from npm 8 to npm 9 (Between Node.js 18.13 and 18.14, see https://nodejs.org/en/download/releases/).

Could you please stop upgrding npm to a version with breaking changes into the LTS release of Node.js ? And possibly into any major version of Node.js since it breaks semver.

It makes it impossible to specify "LTS" as the Node.js target for deployment and forces us to pin and regularly update a specific Node.js version.

[okuryu]

If you haven't seen #778 yet, you might want to.

[MylesBorins]

hey @sonnyp thanks for opening this issue. For the npm team it is critical that we find a path to the Node.js project treating npm Semver Major releases as Semver Minor for Node.js, and I believe that is achievable.

Our intent is to only land breaking changes that are non breaking to Node.js, the most obvious of these are changes to our package.engines field to drop support of old versions of Node.js, which in turn allow us to adopt new language features and update dependencies that have themselves stopped supporting old versions of Node.js.

There is precident for this in the Node.js project, the most obvious of which are updates to V8, which historically were breaking due to ABI compatibility issues, are now able to be done in a non breaking way.

The npm team spent months working with the Node.js team to ensure that the npm 9 release would be non breaking for Node.js. That discussion was tracked here. We released npm 9 and had it shipped for a month before landing in Node.js in main and releasing as part of Node.js 19. We waited another month, without any reports of breaking changes, before backporting to LTS. We extensively tested with CITGM as well to do our best to make sure there would be no breaking changes for Node.js developers with this update.

When a bug report came in about our change to install links being breaking to node, we examined the situation and determined that breaking change was in fact disruptive, reverted it within a couple hours and cut a new release the same day. The only reason it hasn't been able to get out in a Node.js release yet is due to the upcoming security release.

We are hoping to not see many bugs introduced by the breaking changes in npm 9, but we are absolutely up for revisiting and potentially reverting every change that is causing issues for down stream consumers. Further we intend to document / codify the types of changes that are considered breaking to ensure that we never make those types of changes in a future npm Semver Major we expect to land as Semver Minor in Node.js

[sonnyp]

Thanks for engaging 🙏

Our intent is to only land breaking changes that are non breaking to Node.js,

I think this need clarification. Given that Node.js ships with npm - I'd assume any npm breaking change is a Node.js breaking change.

Could clarify what is or isn't a breaking change to Node.js?

In our case – npm ci stopped working as npm couldn't resolve peer dependencies anymore.

Is that considered a Node.js breaking change?

[MylesBorins]

Part of the contract we agreed to was that any npm install / ci that worked before the update should continue to work after the update.

It is very possible that this is a bug, as we haven't made any changes to peer dep behavior in npm 9 intentionally.

Do you have a minimal reproduction? Have you tested with the latest version of 9 where we reverted the install-links change?

It's not impossible that this is just a regression, in which case it has nothing to do with the semver major. If it is a bug we'll prioritize fixing asap.

[sonnyp]

Looks like we are experiencing nodejs/node#46542

I'm completely out of Node.js / npm development and I really don't know the constraints you have to work with.

With that said and regardless of how much QA is being done; I don't think it is reasonable to ship configuration or refactors in the LTS release of Node.js and expect things to go well.

As far as LTS and user expectations goes, the goal of the npm team should be to minimize risks – not update to the new major release.

[gurgunday]

Since this release happened anyway and the message seems to have been received for future releases, I think the issue can be closed?

[lukekarrys]

I do think this issue can be closed, as this is feedback we've taken into consideration for future npm releases.

I've also opened an issue for gathering feedback on our planned release for npm 10 here: #884.