A CI pipeline switches from `npm install` to `npm ci` (or from `yarn install` to `yarn install --frozen-lockfile`) specifically for build reproducibility. What does this strict install mode actually do differently under the hood, and what class of bug does it catch that the regular install command lets through silently?

## A regular install reconciles A regular `npm install` is fundamentally an **incremental, reconciling operation**: it looks at what's already in `node_modules` and the existing lockfile, compares that against `package.json`, and does the minimum work needed to make everything consistent again -- resolving any new or changed ranges, potentially updating the lockfile in the process, and leaving untouched packages alone. That reconciliation is exactly what you want on a developer's laptop day to day (fast, incremental, forgiving), but it's precisely the wrong behavior for a build you intend to promote to production, because 'reconciling' means the installer is allowed to make resolution decisions on your behalf, silently, at build time. ## The three things a strict install does differently `npm ci` (and yarn's frozen-lockfile mode, and pnpm's equivalent) is built for the opposite goal: total determinism with a hard failure on any ambiguity. Concretely, it does three things differently. 1. **First, it deletes any existing `node_modules` directory before installing,** so there's no possibility of stale, hand-modified, or partially-installed leftover files influencing the result -- every build starts from zero. 2. **Second, it skips dependency resolution entirely:** rather than computing which version satisfies each range, it just reads the exact versions and integrity hashes already recorded in the lockfile and installs precisely those, which is also why it's noticeably faster than a full install on a cold cache. 3. **Third** -- and this is the part that actually changes developer behavior -- before doing any of that, it validates that the lockfile is fully consistent with `package.json`: same set of declared dependencies, same version ranges. If there's any discrepancy, `npm ci` refuses to proceed and exits with an error, rather than treating the mismatch as something to fix on the fly. ## Why the strict mode exists **Why this exists:** the whole point of a lockfile is to guarantee 'what gets built is exactly what was reviewed,' and a reconciling install command quietly undermines that guarantee the moment the lockfile and manifest disagree, because it will paper over the disagreement by re-resolving -- possibly pulling in a newer transitive version that was never reviewed in the PR that changed `package.json`. In a CI context specifically, that means a build could pass using a dependency graph nobody actually looked at, and that drift is invisible unless someone happens to notice an unexpected diff in the lockfile after the build runs. By making that exact scenario a hard failure instead, strict install modes force the discrepancy to be caught locally, before merge -- the fix is simply to run a regular install locally to regenerate the lockfile and commit that. ## The trade-off The trade-off is minor and almost entirely upside for CI/production use: the only real cost is that `npm ci` requires a lockfile to exist at all (it errors out if there isn't one) and is deliberately less forgiving, so if a developer legitimately wants to experiment with dependency changes without regenerating the lockfile yet, `npm ci` isn't the right command for that -- you'd use a regular install locally and switch to `npm ci` only in CI/build/deploy stages. There's no meaningful reproducibility trade-off; it's strictly a stricter, faster subset of what a full install does when the lockfile and manifest already agree. ## The failure this catches in practice The failure mode this catches in practice, very concretely: an engineer adds a new package by directly hand-editing `package.json` (or resolves a merge conflict in `package.json` without re-running install afterward) and pushes without realizing the lockfile wasn't regenerated. - **With a plain `npm install` in CI,** the build 'just works' -- the CI machine quietly resolves the new dependency's version and the build succeeds, but the exact version that got installed was never actually reviewed by a teammate and isn't reproducible from the merged commit alone; a rebuild six months later from that same commit could resolve to something different again. - **With `npm ci`,** that same PR fails CI outright with a clear, actionable error pointing at the mismatch, which is the correct outcome: it forces the lockfile regeneration to happen as a reviewable diff in the PR itself. This is precisely why standard CI reference guidance (npm's own docs, common GitHub Actions Node.js setup guidance, and standard Docker multi-stage build patterns for Node apps) recommends the strict install for automated environments and reserves the regular install for local development.