npm v12 Breaking Changes: New Security Defaults for Installation Scripts and Remote Dependencies
npm v12 introduces significant security-related default changes to npm install to mitigate supply-chain vulnerabilities. The primary shift is moving from an automatic execution model to an explicit opt-in model for scripts and remote dependency resolution. These changes are estimated to be released in July 2026, though they are already available as warnings in npm 11.16.0+.
Installation Scripts Disabled by Default
Starting with v12, npm install will no longer automatically execute preinstall, install, or postinstall scripts from dependencies. This change includes implicit node-gyp rebuild operations for packages containing a binding.gyp file, as well as prepare scripts for git, file, and link dependencies.
To manage these scripts, users must now explicitly allow trusted packages:
- Identification: Run
npm approve-scripts --allow-scripts-pendingto identify which packages would be blocked. - Approval: Use
npm approve-scriptsto allow trusted packages andnpm deny-scriptsto block others. - Persistence: The resulting allowlist is stored in
package.jsonand should be committed to version control.
Restricted Git and Remote Dependency Resolution
To close potential code-execution paths, npm v12 restricts how dependencies are resolved from external sources:
Git Dependencies
npm install will no longer resolve Git dependencies (direct or transitive) unless the --allow-git flag is used. This prevents scenarios where a Git dependency's .npmrc could override the Git executable, a vulnerability that persists even when scripts are ignored.
Remote URL Dependencies
Dependencies resolved from remote URLs, such as HTTPS tarballs, will be blocked by default unless the --allow-remote flag is provided. Note that --allow-file and --allow-directory flags will maintain their current defaults in v12.
Preparation and Migration Path
Developers can prepare for the v12 transition by upgrading to npm 11.16.0 or later. In this version, npm provides warnings for behaviors that will be blocked in v12. The recommended workflow is to run a standard installation, review the warnings, and use npm approve-scripts --allow-scripts-pending to build and commit the necessary allowlist in package.json.
Community Perspective and Technical Critique
The announcement has sparked significant discussion among developers regarding the timing and effectiveness of these changes.
Supply Chain Security
Some users noted that these changes address vulnerabilities that have been known for a long time, with one user pointing to a vulnerability reported 10 years ago. There is a general consensus that the move toward an opt-in model is a necessary step to combat supply-chain attacks, though some argue it is a late adoption of patterns already present in other package managers like pnpm.
Effectiveness and Limitations
Critics argue that shifting the execution from the installation phase to the runtime phase does not eliminate the risk, only moves it:
"Now all the malware can move from the install script to the module itself where it will inevitably still be run"
Other developers suggested that a more robust solution would involve sandboxing or simulation runs to output which programs are running before actual execution, rather than relying on an allowlist.
Usability Concerns
There are critiques regarding the CLI ergonomics, specifically the naming of npm approve-scripts --allow-scripts-pending, which some find unintuitive because the command displays a list rather than performing an approval action.