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
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.
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.
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).
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.
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))
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):
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)
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.
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.
Activity
richardlau commentedon May 22, 2025
Also from #58347 (comment) it sounds like there's some sort of issue on Windows with npm 11.4.0?
wraithgar commentedon May 22, 2025
I'll isolate the (relevant) breaking changes here just to help keep folks on one page:
npm initnow has atypeprompt, and sorts the entries the created packages differentlybun.lockbfiles are now included in the strict ignore list during packing--ignore-scriptsnow applies to all lifecycle scripts, includepreparenpm hookcommand has been removedThe 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 commentedon May 22, 2025
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 commentedon May 22, 2025
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 commentedon Jun 13, 2025
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 commentedon Jun 18, 2025
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 commentedon Jun 18, 2025
can we wait on #58696 first?
joyeecheung commentedon Jun 18, 2025
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 commentedon Jun 18, 2025
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):
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 commentedon Jun 18, 2025
We do plan on making a deps update PR to npm 10 to clear the current
npm auditwarnings, 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.jonathandeclan commentedon Jun 19, 2025
with
minimatchversion in v22 usingbrace-expansionwith vulnerability listed in juliangruber/brace-expansion#65 and https://nvd.nist.gov/vuln/detail/CVE-2025-5889 , will this update be considered as higher priority and be done? our application scans are flagging our node alpine containersmcollina commentedon Jun 19, 2025
@jonathandeclan, thanks for making us aware. It might - at the very least, we should get a patch for that in.
wraithgar commentedon Jun 23, 2025
These dependency updates have been done in the
npm@10branch. We're waiting on backporting the powershell script fixes before cutting a v10 release.This work is being done and will still be done irrespective of if npm v11 is introduced into Node.js v22.
RafaelGSS commentedon Jun 24, 2025
minimatchis handled directly on Node.js deps. The update has been created already: #58712jonathandeclan commentedon Jun 26, 2025
Update is created but PR states checks failed and changes are NOT merged.
aduh95 commentedon Jul 2, 2025
Would landing #58847 change something to the current discussion?
alexsch01 commentedon Sep 15, 2025
Any update on this? Been 2 months since the TSC meeting
mcollina commentedon Sep 15, 2025
There is no consensus on upgrading just yet, and so far no one to champion it.
It might happen or not in the future.
I totally forgot to close this, so my bad.
chore: remove napi-postinstall