Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
In a CI/production pipeline, why should you run `npm ci` instead of `npm install`?
💻 Code Challenge | +75 XP
Set up an npm workspaces monorepo with two packages (api and shared-utils) where the api package depends on shared-utils without publishing it to any registry.
Two developers on the same team get different transitive dependency versions installed despite having identical package.json files. Reorder the steps to fix the root cause and prevent recurrence.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant

Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Not committing the lockfile to version control ("it's just generated output")
# Wrong: .gitignore
package-lock.json
# Correct: always commit the lockfile
# (remove it from .gitignore)The Solution //
The lockfile is the actual source of truth for exact resolved dependency versions — package.json alone only specifies acceptable ranges. Without a committed lockfile, every fresh install can resolve slightly different transitive versions over time, causing "works on my machine" bugs that are extremely hard to trace back to a dependency mismatch.
The Error //
Running npm install in a CI/production pipeline instead of npm ci
# Wrong: can silently mutate the lockfile mid-pipeline
npm install
# Correct: fails loudly on any mismatch
npm ciThe Solution //
npm install will happily modify the lockfile to resolve a mismatch between it and package.json, silently masking a real problem (like someone editing package.json by hand without reinstalling). npm ci refuses to do this — it fails the build immediately if the lockfile and package.json disagree, surfacing the issue before it reaches production.