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
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 installbehaviour 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 (
allowScriptsdefaults to off)npm installwill no longer runpreinstall,install, orpostinstallscripts from dependencies unless you have allowed them in your project. This includes nativenode-gypbuilds: a package that ships abinding.gypwith no explicit install script is still blocked, because npm runs an implicitnode-gyp rebuildfor it.preparescripts from git, file, and link dependencies are blocked the same way.You allow scripts per package through a new
allowScriptsfield inpackage.json, managed with two new commands,npm approve-scriptsandnpm 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-gitdefaults tonone)npm installwill 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.npmrccould 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-remotedefaults tonone)npm installwill 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-fileand--allow-directoryflags 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
_authchange (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.jsonfiles.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.0shipped 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 tomainduring the prereleases, a review-ready PR once npm 12 is stable, then backport PRs for the Node 26 and Node 24 release lines.npm@12.0.0-pre.0)12.0.0-pre.1and later)mainnpm@12.0.0)mainmainnpm@12.0.0tolatestmainmainDates are tentative and depend on how prerelease testing goes.
Links