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

01

Understand 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.

nodejsnpmcilockfile

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the 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 r

Solution ready — 2 min read

Classified // press E to declassify

04

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

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.