They can be used safely, but they skip the checks a registry gives you. A branch name or tarball link can change under you, and npm runs a git dependency's prepare script during install. Pin to a full commit, review the source, and prefer a published release when one exists.
What npm accepts
The npm install documentation lists several sources besides registry versions. They include local folders, tarballs (local files or http and https URLs), git remote URLs with an optional commit or semver range, and GitHub style shorthand such as user/repo. Gist, Bitbucket and GitLab shorthands are also listed.
Each is convenient. You can depend on an unreleased fix or a fork without waiting for a publish.
Where the risk comes from
Three things differ from a normal registry install.
First, mutability. A dependency written as user/repo points at a moving default branch. A tag can be moved. The code you tested last week is not guaranteed to be the code you install today unless the lockfile pins a commit.
Second, execution. The documentation says that for git sources, the package's dependencies and devDependencies are installed and its prepare script runs before packaging. So build code from that repository runs on your machine or CI runner.
Third, less scrutiny. Registry packages carry publish history, maintainer records and, sometimes, provenance. A bare URL carries none of that, and many scanners that key off registry metadata match it poorly.
How to use them safely
| Source | Safer form |
|---|---|
| Git repository | Pin to a full commit hash, not a branch or tag |
| Tarball URL | Use a URL you control, with an integrity hash recorded in the lockfile |
| GitHub shorthand | Replace with a published version when the fix ships |
| Local folder | Only for development, not for release builds |
Steps:
- Search package.json and the lockfile for git, github and http dependency specs.
- For each, ask whether a registry release now exists.
- Pin the rest to commits and record why in a comment in your docs.
- Run installs in CI with scripts disabled where you can, and review what the git dependency's prepare step does.
- Add a pull request check that flags new URL dependencies.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a pull request is held when a policy fails. A rule against unpinned URL dependencies fits the same pattern.
Quick check
Does a git dependency run code during install?
Per the npm documentation, its prepare script runs, after its dependencies and devDependencies are installed, before it is packaged and installed.
How do I pin a git dependency?
Reference a specific commit hash instead of a branch or tag, so the resolved code cannot move.
Safeguard policies and PR gates can check dependency changes before merge, and the free scan at gold.safeguard.sh/scan shows what a repository resolves today. Related: how to audit npm postinstall scripts safely.
Sources
Last reviewed: 19 October 2026.
