Plans for npm 12

[JamieMagee]

The npm team is working on npm 12, which is estimated to release in July 2026. I'm opening this issue to discuss the planned breaking changes and to work out how we land them in Node.js, following the same process used for npm 9 (#778) and npm 10 (#884).

npm 12 is a security-focused release. Every breaking change turns an npm install behaviour that runs automatically today into one you opt into. The reason I'm filing this early is that a lot of users have asked for these protections to reach the active release lines, specifically Node 24 and Node 26, rather than waiting for the next major to age into LTS. I'd like the release team's input on whether that's possible.

All of these changes are already available behind warnings in npm 11.16.0 and later, so people can test against them before the major lands. They were announced on the GitHub blog on 9 June 2026, and there is an open community discussion for feedback.

Breaking changes

We plan to follow the guidelines on integrating npm with Node, and we consider the changes below to fall within them.

Install scripts are opt-in (allowScripts defaults to off)

npm install will no longer run preinstall, install, or postinstall scripts from dependencies unless you have allowed them in your project. This includes native node-gyp builds: a package that ships a binding.gyp with no explicit install script is still blocked, because npm runs an implicit node-gyp rebuild for it. prepare scripts from git, file, and link dependencies are blocked the same way.

You allow scripts per package through a new allowScripts field in package.json, managed with two new commands, npm approve-scripts and npm deny-scripts. This is RFC 54. It brings npm in line with pnpm, Yarn, Bun, and Deno, which all block dependency install scripts by default already.

Git dependencies are opt-in (--allow-git defaults to none)

npm install will no longer resolve git dependencies, direct or transitive, unless you allow them with --allow-git. This closes a code-execution path where a git dependency's .npmrc could override the git executable, which ran even with --ignore-scripts. The change was announced on 18 February 2026 and is available in npm 11.10.0 and later.

Remote URL dependencies are opt-in (--allow-remote defaults to none)

npm install will no longer resolve dependencies from remote URLs, such as https tarballs, direct or transitive, unless you allow them with --allow-remote. This is available in npm 11.15.0 and later. The related --allow-file and --allow-directory flags keep their current defaults in npm 12.

Why we'd like these in Node 24 and 26

This is the part I most want the release team's input on.

All three defaults exist to cut off code that runs during npm install, before any application code is imported.The supply-chain attacks of the last two years leaned on exactly this. event-stream, the Lazarus campaigns, the chalk and debug compromise, the Shai-Hulud worm, and the Axios hijack in March all used an install script or install-time resolution as the entry point.

Node's LTS policy already allows a semver-major change to ship as a semver-minor when the reason is security. npm took this path in npm 9 for the unscoped _auth change (see the discussion in #778), and backported it rather than holding it for the newest line. The npm 12 defaults are the same category of change. So I think there's a reasonable case for getting them onto the active lines, where most users actually are, instead of only the next major.

I know that shipping breaking changes into LTS has been contentious in past npm updates (#884), which is why I want to raise this now and work through the concerns together rather than at release time.

Testing

We'll hold npm 12 to the integrating-with-node guidelines: no new failures in Node's own test suite, no new failures installing or testing the citgm package set, and no backwards-incompatible changes to existing package-lock.json files.

As with npm 10, we'll run our node-integration workflow in GitHub Actions against every npm 12 prerelease so regressions show up early, and CI runs on every PR the npm team opens.

Timeline

Prereleases are already underway. npm@12.0.0-pre.0 shipped on 20 May 2026, and the next prerelease (12.0.0-pre.1) is pending in the release PR npm/cli#9387. The goal is to make npm 12 testable inside Node as early as possible: CI-only PRs to main during the prereleases, a review-ready PR once npm 12 is stable, then backport PRs for the Node 26 and Node 24 release lines.

#	Task	Status / target
1	First prerelease (npm@12.0.0-pre.0)	Done, 20 May 2026
2	Further prereleases (12.0.0-pre.1 and later)	In progress (pre.1 pending in npm/cli#9387)
3	CI-only PR(s) to Node.js main	During prereleases
4	Major release (npm@12.0.0)	Targeting July 2026
5	Open review-ready PR to Node.js main	With major release
6	Land npm 12 on Node.js main	After review
7	Promote npm@12.0.0 to latest	July 2026
8	Open PR to backport to Node.js 26	After landing on main
9	Open PR to backport to Node.js 24	After landing on main
10	Release npm 12 in Node.js 26	Tentative
11	Release npm 12 in Node.js 24	Tentative

Dates are tentative and depend on how prerelease testing goes.

Links

• Upcoming breaking changes for npm v12 (GitHub blog)
• Community discussion
• RFC 54: Make install scripts opt-in
• Integrating with node (npm CLI wiki)
• Previous plans: npm 10 (#884), npm 9 (#778)

[ljharb]

I think it's definitely worth it for 26, since it's a pretty new major, it's not LTS yet, and anyone impacted can add

allow-scripts=true
allow-git=all
allow-remote=all

to .npmrc or ~/.npmrc to unblock themselves (although hopefully they wouldn't want to).

For 24 is a tougher sell, but I'd love to hear releasers' thoughts on it.

[richardlau]

My opinion is that this should only land in Node.js 26 and 24 as Node.js security updates. There is a clear Node.js release policy (as mentioned) for this, and there would be more opportunity to communicate the change.

Since there would be options to opt back into the old behaviour, I am in favour of releasing npm 12 in Node.js 24 and 26 in a security release.

[Waldenesque]

@JamieMagee

Would the npm team consider continuing to backport ongoing v12 bugfixes and enhancements for this functionality to v11 if only Node 26 gets updated to npm 12 with Node 24 remaining on npm 11? It sounds like 11.16.0 and 12.0.0 will be equivalent except the new restrictions change from opt-in to opt-out, yet if future patches won't get backported then Node 24 would be stuck with slightly broken or limited functionality. If the npm team is willing to keep v11 refreshed with any nontrivial patches, then identical restrictions could be enforced by default in Node 26 while remaining optional in Node 24.

There is a possibility this staggered scenario could even be better for long-term ecosystem health. If an LTS release suddenly gets this change in a minor update, I suspect lots of people will simply disable the new restrictions, but once that config change has been made it will tend to linger indefinitely, even after they move to subsequent Node versions. That weakens the impact of a new default and reduces pressure on packagers to eliminate these scripts if they're not truly necessary.

If this change remains optional in the present LTS, but Current ships it immediately when npm 12 is released with a few months before going LTS, maybe that time window will allow more packages to eliminate these scripts entirely if possible. Then when Node 26 goes LTS with this new default, more people can leave the new default in place, meaning a larger population of users with these scripts disabled. That in turn deters future packagers from using these scripts if they're not genuinely necessary.

As an extension of this thinking, even if Node 24 does eventually update to npm 12, there might be benefit in waiting to do that switch a little later. For example wait three to six months after Node 26 goes LTS with npm 12, then update Node 24 to npm 12 in early 2027, and announce in the Node blog alongside the Node 26 LTS release post that this switch will happen for Node 24 in a few months. That offers another time window for packages to potentially eliminate these scripts before many users on the older LTS start getting error messages.

Also for the npm team this would limit the time window you'd have to worry about backporting v12 patches to v11. But if you're willing to do this for a limited period of time, you may end up with a better overall new status quo, meaning a smaller number of Node users who've manually configured pre-npm 12 behavior.

Bottom line, I really hope Node 26 updates to npm 12 as soon as it's released. However it may be worth handling Node 24 differently.