What is the purpose of `package-lock.json`? | Interview Question

Q: What is the purpose of `package-lock.json`?

**Target Audience:** Engineers preparing for Node.js phone screens — assumes basic `package.json`/npm familiarity. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The lock-file structure below came from **actually running** `npm install` on this machine and reading the real generated file, not a hand-written example. ## 1. Why This Even Matters — A Story First Two bakers are handed the identical recipe card that says "flour, to taste, a good brand." One bakes today, the other bakes six months from now — and if "a good brand" quietly changed its recipe in that time, the two loaves can come out different, even though both bakers followed the exact same card faithfully. A receipt that says "used Brand X, batch #4471, purchased this specific day" removes that ambiguity entirely. `package-lock.json` is that receipt. ## 2. The Core Idea 📌 **Interview term:** `package.json` declares **ran

The problem

Question presented to candidate: "Two developers run npm install against the identical package.json on different days. What guarantees they end up with the same dependency versions, and what file makes that guarantee possible?"

What a strong answer should cover:

package.json declares dependency ranges (^4.17.20); package-lock.json records the exact version actually resolved for every dependency and transitive dependency in the tree, plus its exact source (a tarball URL and integrity hash).
📌 This is what makes installs reproducible across machines and over time — without it, two installs run on different days could resolve a range like ^4.17.20 to two different actual patch/minor versions if a new one had been published in between.
package-lock.json should be committed to version control — it is not a generated artifact to .gitignore, precisely because its entire value is being a shared, exact record everyone installs from.
npm ci (distinct from npm install) installs strictly from the lock file, deletes node_modules first, and errors out if package.json and package-lock.json are out of sync — this is why CI pipelines use npm ci, not npm install, for reproducible builds.
The lock file also carries an integrity hash (a checksum) for each resolved package, which npm verifies against the downloaded tarball — a defense against a compromised or tampered registry response, not just a version-pinning mechanism.
A precise answer distinguishes "the lock file's job" from "npm's dependency-resolution algorithm" — the lock file is the recorded result, not the resolver itself; understanding it as a recorded artifact (rather than something that itself does the resolving) avoids a common conceptual muddle.

Clarifying questions expected:

"Is the concern reproducibility across developer machines, or reproducibility in CI/CD specifically?" — both are solved by the same mechanism, but the answer's emphasis can differ.
"Yarn or pnpm instead of npm?" — each has its own equivalent lock file format (yarn.lock, pnpm-lock.yaml) serving the identical purpose.

Code / implementation expected: Optional — inspecting a real, freshly generated package-lock.json's structure (the exact version and tarball URL it records) makes the concept concrete rather than abstract.

npm
dependencies
package-lock.json
versioning

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 phone screens — assumes basic package.json/npm familiarity. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The lock-file structure below came from actually running npm install on this machine and reading the real generated file, not a hand-written example.

1. Why This Even Matters — A Story First

Two bakers are handed the identical recipe card that says "flour, to taste, a good brand." One bakes today, the other bakes six months from now — and if "a good brand" quietly changed its recipe in that time, the two loaves can come out different, even though both bakers followed the exact same card faithfully.

A receipt that says "used Brand X, batch #4471, purchased this specific day" removes that ambiguity entirely. package-lock.json is t

The solution is hidden so you can try first

6 min read · 9 sections

Read the code

Reading the real, freshly generated package-lock.json fields directly

$ npm init -y && npm install lodash@4.17.20
$ node -e "
const l = require('./package-lock.json');
console.log(Object.keys(l));
console.log('lockfileVersion:', l.lockfileVersion);
console.log('lodash version:', l.packages['node_modules/lodash'].version);
console.log('lodash resolved:', l.packages['node_modules/lodash'].resolved);
"

# [ 'name', 'version', 'lockfileVersion', 'requires', 'packages' ]
# lockfileVersion: 3
# lodash version: 4.17.20
# lodash resolved: https://registry.npmjs.org/lodash/-/lodash-4.17.20.tgz
#
# package.json only said "^4.17.20" — the EXACT version and source live here.

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.