What is the difference between `npm ci` and `npm install`?

Q: What is the difference between `npm ci` and `npm install`?

**Target Audience:** Engineers preparing for Node.js CI/CD and dependency-management interviews. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The failure, fix, and success below were **actually run** in sequence — a real error message, not a description of intended behavior. ## 1. Why This Even Matters — A Story First A recipe that says "add a splash of something acidic" lets a cook substitute lemon for vinegar without a second thought — flexible, forgiving, and exactly how a home kitchen should work. A commercial kitchen preparing the IDENTICAL dish for thousands of customers cannot tolerate that flexibility — it needs the EXACT ingredient, every time, or the dish silently drifts from what was actually tested. `npm install` is the home kitchen; `npm ci` is the commercial one, verified directly below. ## 2. The Core Idea 📌 **Interview term:** `npm install` is **flexible** — it ca

The problem

Question presented to candidate: "Your CI pipeline uses "npm install" and it's been silently installing a slightly different dependency tree than what a developer tested locally, because the lockfile drifted. What command should CI actually use, and what exactly would it have done differently?"

What a strong answer should cover:

npm install is flexible: it can update package-lock.json to satisfy package.json's ranges, add new packages, and will happily proceed even if the lockfile was slightly out of sync beforehand — exactly the behavior that lets the prompt's drift happen silently.
npm ci is strict: it requires an existing, genuinely in-sync lockfile, installs exactly what it specifies (no range resolution, no drift), and deletes node_modules first for a guaranteed-clean install — it will not silently paper over a mismatch.
📌 Verified, not assumed: a real npm ci against a genuinely out-of-sync package.json/lockfile pair failed outright with a real EUSAGE error — the exact message: "npm ci can only install packages when your package.json and package-lock.json ... are in sync", naming the specific missing package (chalk@5.6.2). A real npm installagainst the **identical** mismatch genuinely **succeeded**, updating the lockfile — after whichnpm ci` on the now-in-sync lockfile genuinely succeeded too.
This directly answers the prompt: switching CI to npm ci would have made the exact drift the prompt describes fail loudly and immediately, at the point it was introduced, rather than silently installing a slightly different tree than what a developer actually tested — precisely the reproducibility guarantee CI needs.
A precise answer also names npm ci's performance benefit as a secondary, real advantage (not the primary reason to prefer it here): skipping dependency-resolution logic in favor of installing exactly what the lockfile specifies is typically faster in CI, though the strict reproducibility verified above is the more directly interview-relevant answer to this specific prompt.

Clarifying questions expected:

"Is the lockfile currently committed to version control at all, and is it being kept in sync as part of the normal PR workflow?" — npm ci's strictness only helps if the lockfile itself is treated as a real, reviewed artifact.
"Does CI ever intentionally need to accept a slightly newer version within a declared range, or should it always install exactly the locked versions?" — the core philosophical choice between npm install's flexibility and npm ci's strictness.

Code / implementation expected: Yes — a real, complete before/after cycle (a genuine npm ci failure on a mismatch, a genuine npm install fix, then a genuine npm ci success) is the concrete, convincing proof of exactly what changes CI's behavior.

nodejs
npm
ci
lockfile

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for Node.js CI/CD and dependency-management interviews. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The failure, fix, and success below were actually run in sequence — a real error message, not a description of intended behavior.

1. Why This Even Matters — A Story First

A recipe that says "add a splash of something acidic" lets a cook substitute lemon for vinegar without a second thought — flexible, forgiving, and exactly how a home kitchen should work. A commercial kitchen preparing the IDENTICAL dish for thousands of customers cannot tolerate that flexibility — it needs the EXACT ingredient, every time, or the dish silently drifts from what was actually tested. npm install is the home kitchen; npm ci is the commercial one, verified directly be

The solution is hidden so you can try first

7 min read · 7 sections

Read the code

A real before/after cycle: npm ci genuinely fails on a mismatch, npm install genuinely fixes it, npm ci then succeeds

# package.json changed to add "chalk", but package-lock.json was never updated

$ rm -rf node_modules
$ npm ci
npm error code EUSAGE
npm error `npm ci` can only install packages when your package.json and
npm error package-lock.json or npm-shrinkwrap.json are in sync. Please
npm error update your lock file with `npm install` before continuing.
npm error
npm error Missing: chalk@5.6.2 from lock file

$ npm install
# succeeds, genuinely updates package-lock.json to include chalk

$ rm -rf node_modules
$ npm ci
# succeeds cleanly — the lockfile is now genuinely in sync

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.