Update npm to v11 in Node.js v22

[mcollina]

We should update NPM to v11 in Node.js v22 to work around this bug npm/cli#8184.

It's causing some friction with a lot of users.

What are the breaking changes? According to https://github.com/npm/cli/blob/latest/CHANGELOG.md doesn't look like there are many.

cc @nodejs/npm @nodejs/releasers

[richardlau]

What are the breaking changes?

• deps: upgrade npm to 11.0.0 #56274 (comment)
• deps: upgrade npm to 11.0.0 #56274 (comment)

Also from #58347 (comment) it sounds like there's some sort of issue on Windows with npm 11.4.0?

[wraithgar]

I'll isolate the (relevant) breaking changes here just to help keep folks on one page:

• Upon publishing, in order to apply a default "latest" dist tag, the command now retrieves all prior versions of the package. It will require that the version you're trying to publish is above the latest semver version in the registry, not including pre-release tags.
• npm init now has a type prompt, and sorts the entries the created packages differently
• bun.lockb files are now included in the strict ignore list during packing
• When publishing a package with a pre-release version, you must explicitly specify a tag.
• --ignore-scripts now applies to all lifecycle scripts, include prepare
• npm will no longer fall back to the old audit endpoint if the bulk advisory request fails.
• npm will no longer switch to global mode if aliased to "npmg" or "npm-g" etc.
• The npm hook command has been removed
• Attestations made by this package will no longer validate in npm versions prior to 10.6.0

The Windows issue is isolated to Powershell users, and is being worked on. The bugs that the new code is trying to fix exists in npm 10 already, and we are waiting on backports till it is all worked out.

[alexsch01]

The biggest breaking change / annoyance is the deprecation warning for non-NPM config options in .npmrc files

@wraithgar for that Windows issue, I just finished fixing the redirection

[ljharb]

I agree; all the rest of them are preventing footguns, so even if users are annoyed, they'll figure out the explicit better path easily. That config one, though, might cause some friction.

[ShogunPanda]

My 2 cents here.

I think we should upgrade NPM in Node 22 to version 11 as suggested in this issue.
The breaking changes in NPM 11 can be easily fixed by users when upgrading.

It's better if it happens now that Node 22 is still Active LTS as part of semver-minor release rather than anytime in the future when Node 22 is Mainteinance LTS and we have to do as part of a security release and thus during a semver-patch release.

Moreover, I'm not really comfortable in having a LTS version ship a major component in the ecosystem which is not officially supported by the creators (TLDR: NPM has no LTS policy).

[BridgeAR]

I believe we should backport the update to Node.js v22. We know about the difficulty with the support ranges and this was the way we handled it before. The breaking changes are also not seemingly difficult for users.

[alexsch01]

can we wait on #58696 first?

[joyeecheung]

I wonder what's the opinion from @nodejs/npm @wraithgar about which version is going to cause more problems? Is updating it going to cause more friction (for most people) than updating it, or the other way around? (asking because it's not clear to me from #58423 (comment))

[wraithgar]

Back during npm 9 this was something that was discussed. It ultimately resulted in a list of "breaking changes rules" for integrating with node from npm's side that lives at https://github.com/npm/cli/wiki/Integrating-with-node. This was intended as a guide for this very scenario.

I followed a few issues that resulted from this but the policies that resulted didn't go into any detail along these specific lines (back-porting semver major releases):

• doc: add policy for distribution #51918
• doc: add policy for executables #51994
• doc: add policy for “placeholder” executables #52107

There was also discussion in the original npm 11 PR around why this wasn't ported to node 22 at the time: #56274

From npm's perspective this does not constitute a breaking change in any core functionality (e.g. in installing packages). The biggest changes, as has been stated earlier, are npm now exiting on error states that prevent future problems. Publish and init for example, not install.

So far the new undefined config warnings are the ones receiving the most feedback. These are only warnings and nothing is a breaking change there.

(edited to highlight npm's "tldr" response to the previous question)

[wraithgar]

We do plan on making a deps update PR to npm 10 to clear the current npm audit warnings, but getting it into a PR for node 22 is still tbd because of the as yet un-triaged bug in making the backport PRs to node.