What is the difference between dependencies, devDependencies, and peerDependencies?

Q: What is the difference between dependencies, devDependencies, and peerDependencies?

**Target Audience:** Engineers preparing for Node.js phone screens — assumes basic npm familiarity. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The install behavior below came from **actually running** `npm install --save-dev` and a subsequent `npm install --omit=dev` on this machine, not a description of expected behavior. ## 1. Why This Even Matters — A Story First A moving company packs two very different kinds of things: furniture that goes into the new home, and the packing tape, boxes, and dollies used only to get it there. Nobody unpacks the moving equipment into the new living room — it did its job during the move and gets left behind. Shipping it along anyway would just be wasted weight in the truck. `devDependencies` are the packing tape and dollies. `dependencies` are the furniture. ## 2. The Core Idea 📌 **Interview term: `dependencies`** — packages the app genuinely

The problem

Question presented to candidate: "Your production Docker image installs with npm install --omit=dev, and the app crashes because a package it imports at runtime is missing. What is the likely mistake in package.json?"

What a strong answer should cover:

"dependencies" are packages the application needs at runtime in production — anything actually required/imported by code that runs when the app is live.
"devDependencies" are packages needed only for development and build tooling — test runners, linters, TypeScript, bundlers — never imported by the shipped runtime code itself.
📌 The concrete, verifiable consequence: npm install --omit=dev (or the older --production flag) installs only "dependencies", skipping everything under "devDependencies" entirely — the exact bug in the prompt is a runtime import placed in "devDependencies" by mistake.
"peerDependencies" are different in kind, not just in timing: they declare that this package expects the consuming project to already provide a compatible version of something (a classic example: a plugin declaring the specific version range of the framework it plugs into) — npm does not automatically install a peer dependency's package the way it does regular dependencies; it instead warns if a compatible version is missing or the wrong version is present in the consuming project.
"optionalDependencies" (less commonly asked about, but worth naming precisely if it comes up) behave like regular dependencies except an install failure for one of them does not fail the whole install — used for packages that provide an enhancement but are not strictly required.
A precise answer keeps the framing correct: this is fundamentally about when and for whom a package is needed (build-time-only tooling vs. runtime code vs. "the consumer is expected to already have this"), not merely a stylistic categorization choice.

Clarifying questions expected:

"Is this package imported by code that runs in production, or only used by a build/test script?" — the actual deciding question between dependencies and devDependencies.
"Is this project a library meant to be installed by other projects, or an application?" — peerDependencies matters far more for the former.

Code / implementation expected: Yes — demonstrating npm install --save-dev correctly placing a package under devDependencies, and a production-style install skipping it, is the concrete, convincing proof.

npm
package
architecture

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 npm familiarity. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The install behavior below came from actually running npm install --save-dev and a subsequent npm install --omit=dev on this machine, not a description of expected behavior.

1. Why This Even Matters — A Story First

A moving company packs two very different kinds of things: furniture that goes into the new home, and the packing tape, boxes, and dollies used only to get it there. Nobody unpacks the moving equipment into the new living room — it did its job during the move and gets left behind. Shipping it along anyway would just be wasted weight in the truck.

devDependencies are the packing tape and dollies. dependencies are the furniture.

The solution is hidden so you can try first

6 min read · 9 sections

Read the code

npm --save-dev placing a package under devDependencies, then --omit=dev correctly skipping only that one

$ npm install --save-dev typescript@5.3.3
$ cat package.json
# {
#   "dependencies": { "lodash": "^4.17.20" },
#   "devDependencies": { "typescript": "^5.3.3" }
# }

$ rm -rf node_modules
$ npm install --omit=dev
$ ls node_modules | grep -E "^(typescript|lodash)$"
lodash
# typescript is genuinely absent — a devDependency skipped by a production-style install

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.