Why package-lock.json must be committed

WHAT THIS TESTS This checks whether you understand that semver ranges in package.json are intentionally loose and that real reproducibility comes from the lockfile. It is a maturity signal about build determinism and supply-chain safety.

A GOOD ANSWER COVERS package.json typically uses ranges such as caret or tilde, so it specifies acceptable versions rather than exact ones. Without a lock, npm is free to pick the newest matching version at install time, and transitive dependencies you never named can drift independently. package-lock.json captures the exact version, the resolved URL, an integrity hash, and the full tree structure for every direct and transitive package. With it committed, anyone running an install, including CI, reconstructs the same tree, so a build that passed yesterday behaves the same today. Using npm ci reads the lock strictly and fails if it disagrees with package.json, which is ideal for pipelines.

COMMON WRONG ANSWERS Believing package.json alone pins exact versions, treating the lockfile as disposable generated noise that should be gitignored, or routinely deleting it to resolve merge conflicts instead of resolving them properly.

LIKELY FOLLOW-UPS The difference between npm install and npm ci, how the integrity hash protects against tampered packages, how to resolve lockfile merge conflicts, and lockfile equivalents in yarn and pnpm.

ONE CONCRETE EXAMPLE A dependency listed as a caret range publishes a buggy new minor version overnight. A teammate who installs without a committed lock pulls the broken version and sees failures you cannot reproduce, because your machine resolved an older one. With package-lock.json committed, both of you get the exact same pinned version, the bug never sneaks in unnoticed, and an intentional upgrade shows up as a reviewable diff.