Short answer: npm v12 is now generally available, and it changes three important install behaviors from automatic to opt-in. Dependency lifecycle scripts and implicit node-gyp builds are blocked unless approved; Git dependencies are blocked unless allowed; and remote URL dependencies are blocked unless allowed. Before updating a production build, test in a branch, review pending scripts, approve only packages you trust, and commit the resulting allowScripts policy.
npm v12 migration checklist
- Inventory npm versions used on developer machines, CI runners, containers and deployment services.
- Create a migration branch and keep the first v12 test away from production.
- Run a clean install using the same command your CI system uses, such as
npm ci. - List unapproved install scripts with
npm approve-scripts --allow-scripts-pending. The npm docs describe this mode as read-only. - Review each package before approving it. Confirm why it needs an install script and whether the installed version is expected.
- Approve trusted dependencies with
npm approve-scripts; explicitly block packages where appropriate withnpm deny-scripts. - Commit the resulting
package.jsonchange with the lockfile so local and CI policy stay aligned. - Search for Git and remote URL dependencies because
--allow-gitand--allow-remotenow default tonone. - Test native modules and binary-dependent packages, since implicit
node-gypbuilds are covered by the new script policy. - Run the full build and test suite, including fresh containers and cache-free CI jobs.
- Audit npm publishing automation ahead of the separate 2FA-bypass token restrictions described below.
What changed in npm v12?
| Area | npm v12 default | What teams should check |
|---|---|---|
| Dependency install scripts | Blocked unless allowed | preinstall, install, postinstall and implicit node-gyp builds |
| Git dependencies | --allow-git=none | Direct and transitive Git sources |
| Remote URL dependencies | --allow-remote=none | Direct and transitive HTTPS tarballs or other remote URLs |
GitHub announced the general availability of npm v12 on July 8, 2026. A live npm registry check during preparation of this guide returned 12.0.1 as the latest npm package version. Version availability can change, so verify the release selected by your package manager or CI image before rollout.
Commands to use during migration
# Record the versions used in the test environment
node --version
npm --version
# Install exactly from the lockfile, using your normal CI workflow
npm ci
# Read-only: list packages with install scripts not covered by policy
npm approve-scripts --allow-scripts-pending
# Interactively approve scripts you have reviewed and trust
npm approve-scripts
# Explicitly deny a reviewed package when appropriate
npm deny-scripts
# Review and commit the policy change
git diff -- package.json package-lock.jsonDo not use npm approve-scripts --all as a shortcut without review. npm supports that option, but bulk approval weakens the value of an explicit allowlist. The v12 docs also say approvals are pinned to the installed package version by default; using --no-allow-scripts-pin creates a name-only approval that can cover future versions, so version-pinned approval is the safer starting point.
What may break after the upgrade?
- Native addons: a dependency with
binding.gypmay depend on an implicitnode-gyp rebuild. - Binary setup: some packages use install scripts to prepare required binaries or assets.
- Git-based packages: both direct and transitive Git dependencies need explicit permission.
- HTTPS tarball dependencies: remote URL sources are no longer resolved automatically.
- Global tools and
npx: the project-level approval command cannot write policy where there is no projectpackage.json. npm’s documentation points to the--allow-scriptsinstall flag or user-level configuration for those contexts. - Workspaces: npm’s v12 command documentation warns that
approve-scriptsis unaware of workspaces, so monorepo teams should test policy behavior carefully in their own layout.
How allowScripts works
The allowScripts field in package.json records which dependencies may run install scripts. Uncovered dependency scripts are skipped, and npm reports skipped packages after installation so they can be reviewed. Approving a package normally writes a version-pinned entry. Denying a package writes a name-only false entry, which remains denied even if someone later runs bulk approval.
Review the generated diff rather than copying a generic allowlist from another project. Two applications can have different dependency versions, lockfiles and build requirements even when they use similar frameworks.
Separate npm token deadlines to prepare for
The July 8 announcement also begins a separate deprecation for granular access tokens configured to bypass 2FA. GitHub says these tokens are expected to stop bypassing 2FA for sensitive account, package and organization management actions in early August 2026. The announcement says direct publishing with those tokens is expected to end around January 2027, with trusted publishing via OIDC or staged publishing named as the migration paths.
- Find CI secrets that use npm granular access tokens.
- Identify jobs that change access, maintainers, organizations, teams or trusted-publishing configuration.
- Move automated publication toward npm trusted publishing where supported, rather than relying on a long-lived publish token.
- Keep a human approval path where staged publishing fits the release process.
Practical rollout plan
1. Observe
Map every environment that installs dependencies. If an older npm version is still in use, GitHub says npm 11.16.0 and later can surface warnings that help teams prepare for v12 behavior.
2. Review
Generate the pending list, inspect package purpose and version, and approve only what the build genuinely requires. Record the reason in the pull request for future reviewers.
3. Verify
Run clean installs on all supported operating systems and architectures, then execute build, unit, integration and deployment tests. A cached development install is not enough to prove a clean CI build works.
4. Enforce
Commit policy changes, pin the npm major version used by CI, and require review when a dependency update changes the script allowlist or introduces a new source type.
FAQ
Does npm v12 run dependency install scripts automatically?
No. Dependency preinstall, install and postinstall scripts, plus implicit node-gyp builds, are blocked unless explicitly allowed.
How do I see which scripts npm v12 would block?
Run npm approve-scripts --allow-scripts-pending inside a project with package.json. npm documents this as a read-only listing mode.
Will npm v12 install Git or remote URL dependencies?
Not by default. --allow-git and --allow-remote now default to none, so those sources require explicit permission.
Should the script allowlist be committed?
Yes. GitHub’s migration guidance says to approve the scripts you trust and commit the resulting package.json allowlist.