Set blockExoticSubdeps to true in pnpm. It prevents transitive dependencies from using exotic sources such as git repositories or direct tarball URLs, so everything below your direct dependencies resolves from trusted sources. It closes a gap that version pinning and registry checks do not cover.
What counts as exotic
A normal dependency is a name and version that resolves through a package registry. An exotic one points elsewhere: a git URL, a branch name, or a link to a tarball hosted on some server. The pnpm supply chain guidance uses exactly these examples.
Why exotic sources are riskier
Registry packages come with a version history, a publisher account and, increasingly, signatures or provenance. A git branch or a tarball URL has none of that by default. A few specific problems follow:
- Mutable targets. A branch name points at whatever the owner pushes next. A tarball URL can serve different bytes tomorrow.
- Weaker review trail. Registry scanning and removal processes do not apply to a file on a random host.
- Hidden depth. You may never have chosen the exotic source. A dependency three levels down did.
The last point is why the pnpm setting targets transitive dependencies. You can read your own package.json. You are unlikely to read the manifests of every dependency of every dependency.
How to turn it on
Add the setting to the workspace configuration file that pnpm reads:
blockExoticSubdeps: true
Then run an install. If something in the tree uses an exotic source, the install will tell you which dependency, and you can decide what to do.
Handling the findings
- Check whether the dependency publishes the same code to the registry. Often it does, and a newer version avoids the exotic reference.
- If not, ask whether you need the parent package. Replacing it may be cheaper than carrying the exception.
- If you must keep it, pin the source to an immutable reference you have reviewed, and record the reason in the repository.
- Do not turn the setting off globally to make an error go away.
Where it sits with other controls
The same pnpm guidance describes delaying updates with a minimum release age, blocking risky postinstall scripts and a trust policy that rejects packages whose trust evidence has decreased. Exotic source blocking is one more layer, aimed at where code comes from rather than when it was published.
None of these tell you whether a given package is vulnerable. For that you need a dependency inventory and advisory data that you check regularly.
A quick audit before you enable it
If you want to know what you will hit, search your lockfile for entries that point at git hosts or tarball URLs instead of registry versions. The list is usually small, and each entry deserves a decision. Doing this review once, before turning the setting on, avoids a surprise failure in the middle of a release.
If you want a quick look at what your projects actually resolve, Safeguard offers SBOM and dependency scanning, and there is a free scan at gold.safeguard.sh/scan.
Quick check
Does this setting affect my direct dependencies?
The pnpm documentation describes it for transitive dependencies, the packages your dependencies pull in.
What if a needed package uses a git dependency?
Look for a registry version first. If there is none, pin an immutable reference you reviewed and document the exception.
Sources
Last reviewed: 19 October 2026.
