Explain the purpose of `package.json` and `npm`. | Interview Question

Q: Explain the purpose of `package.json` and `npm`.

**Target Audience:** Engineers preparing for Node.js phone screens — no prior npm experience assumed. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The file contents below came from **actually running** `npm init -y` and `npm install` on this machine, not a hand-written example. ## 1. Why This Even Matters — A Story First A shopping list says "a loaf of bread" — not the specific loaf, not which store, not the exact price paid. Whoever does the actual shopping (the store trip itself) decides which precise loaf satisfies "a loaf of bread" today, and keeps the receipt showing exactly what was bought, for next time. `package.json` is the shopping list. `npm` is the person who does the shopping. `package-lock.json`, covered separately, is the receipt. ## 2. The Core Idea 📌 **Interview term: `package.json`** is a **manifest** — a declarative description of the project (name, version, e

01

Understand the problem

Question presented to candidate: "A new teammate asks what package.json actually does versus what npm does. How do you explain the division of responsibility between the two?"

What a strong answer should cover:

package.json is a declarative manifest: the project's name, version, entry point, scripts, and — most importantly for this question — its dependencies, each expressed as a semver range (e.g. ^4.17.20), not a single pinned version.
npm (Node Package Manager) is the tool that reads that manifest and acts on it: resolving each dependency's range to an actual version, downloading it from the registry, laying out node_modules, and running the scripts declared in package.json's "scripts" field via npm run <name>.
📌 The precise distinction worth stating: package.json describes intent (what range of versions is acceptable); the actual, exact versions that were resolved and installed are recorded separately, in package-lock.json — covered in its own dedicated question.
npm is also the interface to the npm registry, the public (or private) package repository npm install <package> downloads from — package.json has no knowledge of the registry itself, only of the range it wants satisfied from it.
"scripts" in package.json is a common source of confusion: it is not a build system, just a named-command shortcut table (npm run build → whatever shell command "build" maps to) that also gets the project's local node_modules/.bin added to PATH for that command.
A precise answer also names that npm is one of several compatible package managers (Yarn, pnpm) that all consume the same package.json format — the manifest format is a de facto ecosystem standard, not npm-proprietary, even though npm is the default bundled with Node.

Clarifying questions expected:

"Is the question about the file format, the CLI tool, or the registry?" — these are three distinct things commonly bundled under "npm."
"Does the team use npm specifically, or Yarn/pnpm against the same package.json?" — decides how much of the answer should be npm-CLI-specific versus format-general.

Code / implementation expected: Optional — showing a real, freshly generated package.json after npm init and npm install is a clean way to ground the answer in something concrete rather than a description.

npmpackage.jsondependenciestooling

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 phone screens — no prior npm experience assumed. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The file contents below came from actually running npm init -y a

Solution ready — 2 min read

Classified // press E to declassify

04

Read the code

A real package.json generated by npm init + npm install, showing a semver range rather than a pinned version

$ npm init -y
$ npm install lodash@4.17.20
$ cat package.json

The resulting package.json content

{
  "name": "pkg-test",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": { "test": "echo \"Error: no test specified\" && exit 1" },
  "license": "ISC",
  "type": "commonjs",
  "dependencies": {
    "lodash": "^4.17.20"
  }
}
// Note the "^" — a semver RANGE (4.17.20 or a later compatible 4.x), not a pin.
// The exact resolved version lives separately, in package-lock.json.

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

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