Some JavaScript teams commit their entire node_modules folder to git instead of relying on npm install at build time. What does this buy them, and why has it fallen out of favor as a default practice?

## What committing node_modules means Committing `node_modules` to version control is the JavaScript ecosystem's most literal expression of full **vendoring**: rather than treating `npm install` (or `pnpm install/yarn install`) as a required build step that fetches every dependency's files from the npm registry, a team runs it once, gets the resulting folder tree of installed packages, and checks that folder directly into git alongside the application source. From that point on, anyone who clones the repository already has every dependency's exact files on disk — no install step needed, no network call, and no possibility that a registry serves a different artifact today than it did when the folder was originally generated. This was a genuinely popular practice in parts of the Node ecosystem in the mid-2010s, partly because npm's early versions (before `package-lock.json` existed, introduced in npm 5 in 2017) offered weaker reproducibility guarantees than modern tooling does — without a lockfile, `npm install` could resolve slightly different transitive versions on two different machines or two different days, so committing the literal installed output was, for a while, one of the few ways to guarantee everyone on a team and in CI was running byte-identical dependency code. ## The benefits The benefits mirror general vendoring benefits but are sharpened by specifics of the npm ecosystem. - `node_modules` trees are notoriously **deep and numerous** — a moderately complex frontend app can easily pull in many hundreds of transitive packages. - The npm registry, being a single, heavily-used, publicly writable service, has had real **availability incidents** and high-profile **trust incidents** (the **left-pad** unpublish event in 2016 being the canonical example, where an author unpublished an 11-line utility package that thousands of projects depended on transitively, instantly breaking builds across the ecosystem). Teams burned by an outage or an unpublish event at a bad moment — mid-deploy, mid-CI-run — sometimes reached for committing `node_modules` specifically as insurance against that class of failure, since a checked-in folder can never be unpublished out from under you. ## The costs The costs, though, are what pushed this from common practice to a discouraged one for most teams today. 1. **Repository size** is the most visible: `node_modules` trees routinely reach hundreds of megabytes to low gigabytes for larger applications, and committing that means every clone, every CI checkout, and every fetch operation gets proportionally slower, with git's storage model compounding this over time as the tree changes across many commits. 2. **Diff review** is the second major cost: a single `npm install` after a dependency bump can rewrite tens of thousands of lines across hundreds of files, which no human reviewer will meaningfully read, so code review of dependency changes becomes theater rather than substance — exactly the opposite of the audit benefit vendoring is supposed to provide. 3. Third, and specific to Node, is the **native-binary-addon problem**: some npm packages (`bcrypt`, `sharp`, various database drivers) ship or compile native code specific to the installing machine's OS and CPU architecture; a `node_modules` tree committed on a Mac developer's laptop can contain binaries that are simply wrong — and fail to load — on a Linux CI runner or production container, a footgun unique to this style of vendoring that a fresh `npm install` on the target platform avoids entirely. 4. Fourth, and the one with the most serious long-term consequence, is the same **vulnerability-scanning blind spot** general vendoring creates: tools like `npm audit`, Dependabot, and Snyk are built to read `package.json` and `package-lock.json` and check declared versions against CVE databases; a committed `node_modules` tree isn't the thing those tools primarily reason about, so a team relying on it as their source of truth can drift out of sync with what their manifest says and lose automated coverage of known vulnerabilities in their actual shipped dependency code. ## Why it fell out of favor The practice fell out of favor specifically because npm's tooling closed the reproducibility gap that originally motivated it: `package-lock.json` (and equivalent lockfiles in Yarn and pnpm) now records the exact resolved version and a cryptographic integrity hash for every package in the tree, so `npm ci` (the CI-oriented install command, stricter than `npm install`) reproduces byte-identical results from the lockfile alone, without needing the tree itself committed. Pairing that lockfile with a private registry mirror or cache (Verdaccio, Artifactory) gets teams the availability and reproducibility guarantees that motivated committing `node_modules` in the first place, without the repo bloat, unreviewable diffs, cross-platform binary problems, or the security-scanning blind spot — which is why `package-lock.json` plus .gitignore-ing `node_modules` is now the near-universal default, and committing the folder itself is reserved for edge cases like genuinely offline/air-gapped deployment pipelines.