An npm upgrade can expose a dependency you did not know came directly from a Git repository. npm 12 stops resolving Git dependencies unless the project explicitly permits them, including Git URLs hidden several levels down the dependency tree.

The useful question is not whether the release sounds modern. It is whether the changed default or capability affects the way your project installs, compiles, resolves modules, or runs in production.

Quick answer

Find the package that introduces the Git URL, prefer a normal registry release when one exists, and use --allow-git only for repositories and protocols your project has deliberately reviewed.

npm install --allow-git=github.com

# Inspect lockfile references before approving
rg "git\+|github.com" package-lock.json

what changed

--allow-git now defaults to none. The change makes Git-based code retrieval an explicit policy decision instead of an invisible side effect of npm install.

This is a version-specific change. Pin the tool or runtime while migrating so a teammate and CI do not test a different contract by accident.

where teams will notice it

Git dependencies are harder to reproduce than registry packages when they point at branches or mutable tags. They can also bypass registry provenance and normal package scanning workflows.

A small smoke test is more useful than assuming the changelog covers your architecture. Reproduce the workflow from a clean checkout with the same command production uses.

a safe migration

  1. Search both package.json and the lockfile for Git URLs.
  2. Trace each URL to the direct dependency that requested it.
  3. Replace branches and tags with immutable commits if Git is unavoidable.
  4. Limit the allowed host and verify the commit in a clean install.

Change one resolution or security boundary at a time. That keeps failures attributable and makes rollback straightforward.

the mistake to avoid

Do not set a broad global allowance on developer machines while leaving CI unexplained. The project should carry a reviewable policy that behaves the same everywhere.

Avoid broad compatibility switches unless they are temporary, documented, and assigned a removal date. A migration that merely hides the warning will return as a harder TypeScript, Node, or npm upgrade later.

how to verify the result

Regenerate the lockfile in a clean checkout and confirm every accepted Git dependency resolves to the expected repository and commit. Review the diff before merging.

Record the tool version and verification command in the pull request. That gives reviewers evidence and gives the next upgrade a known baseline.

rollout note

Ship the change in a small pull request that records the old behavior, the new behavior, and the rollback command. For an application, test the production image rather than only the developer machine. For a library, install the packed tarball in a tiny consumer project. Keep the previous lockfile or compiler configuration available until CI, deployment, and one real workflow have all passed.

That evidence makes the upgrade reviewable. It also prevents a later failure from being blamed vaguely on the entire major release when one setting or experimental flag was responsible.

official reference

Check the linked documentation again before upgrading production. Current-release features and announced security timelines can change in later patch releases.