Most teams should not commit node_modules. A lockfile with integrity hashes gives reproducible installs without thousands of files in git. Teams that want offline, install-free checkouts can use Yarn Zero-Installs instead, which commits one zip archive per package, but changes to those archives must be reviewed.
Why people consider it
Vendoring means keeping a copy of your dependencies in your own repository. The appeal is clear: builds work offline, a registry outage cannot break you, and a package removed upstream cannot disappear from under you.
The cost is review. A pull request that touches a vendored directory can contain hundreds of changed files. Nobody reads those, so a tampered file can slip in. The Yarn caching documentation also argues against committing node_modules: it holds thousands of files, hoisting moves them around, and manual edits often get committed by accident.
What Yarn Zero-Installs does differently
Per the Yarn docs, Zero-Installs combine Plug'n'Play with an offline mirror. You turn off the global cache, keep packages in a project folder (.yarn/cache by default), and commit that folder with the loader file. Each package is one zip archive, which git handles far better than a node_modules tree. A checkout then works like an install.
Trade-offs the docs name: packages with native dependencies still need an install when added or removed, and the approach depends on Plug'n'Play and the offline mirror.
For third-party pull requests, the Yarn install reference recommends the check cache option in CI. It refetches every package and verifies checksums against the lockfile and any existing cache files, so a modified archive is caught.
Comparing the three approaches
| Approach | Reproducible | Works offline | Review burden |
|---|---|---|---|
| Lockfile and clean install | Yes | No, needs a registry or mirror | Low, lockfile diff |
| Zero-Installs | Yes | Yes | Medium, needs cache verification in CI |
| Committed node_modules | Yes | Yes | High, huge diffs |
A sensible default
- Commit the lockfile and install with the frozen or clean mode in CI.
- If you need offline resilience, put a registry mirror in front rather than vendoring.
- If you adopt Zero-Installs, run the cache verification step on every pull request from outside your team.
- Never let a contributor change vendored files and lockfiles in the same unreviewed commit.
Quick check
Does a lockfile make node_modules in git unnecessary?
For reproducibility, yes. The lockfile pins versions and integrity hashes, and a clean install rebuilds the same tree. Vendoring only adds offline resilience.
What does Yarn's check cache option do?
It refetches every package and verifies the checksums against the lockfile and existing cache files. Yarn recommends it in CI with Zero-Installs when accepting third-party pull requests.
Safeguard scans dependencies from a lockfile or manifest into an SBOM, so you can inspect what is pinned without vendoring it. Try the free scan at gold.safeguard.sh/scan, and see what a lockfile is and why to commit it.
Sources
Last reviewed: 19 October 2026.
