What are npm workspaces and how do you manage a monorepo with them?

Q: What are npm workspaces and how do you manage a monorepo with them?

**Target Audience:** Engineers preparing for Node.js tooling and monorepo-architecture interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The symlink creation and cross-package resolution below were **actually run** — a real `npm install`, real `ls -la` output confirming genuine symlinks, and a genuine live-edit visible through them. ## 1. Why This Even Matters — A Story First Two roommates sharing one refrigerator do not each need to separately buy and stock identical groceries — one shared fridge, visible and usable by both, with changes one makes immediately visible to the other. npm workspaces give a monorepo's packages the same shared fridge: one install, one `node_modules`, and — the prompt's exact question — automatic, live, zero-manual-step visibility of each other's current code. ## 2. The Core Idea 📌 **Interview term:** **npm workspaces** let a root `package.jso

The problem

Question presented to candidate: "You have two related packages — a shared utils library and an app that depends on it — both under active development in the same repo. How do you develop against the LATEST local utils code without publishing it to a registry or manually running npm link every time you make a change?"

What a strong answer should cover:

npm workspaces let a single root package.json declare multiple sub-packages (via a "workspaces" field, typically a glob like "packages/*") that npm install manages together from one root install — a single node_modules, a single lockfile, and (this is the prompt's exact answer) automatic local linking between workspace packages that depend on each other.
📌 Verified, not assumed: a real npm install at the root of a genuine two-package workspace (@demo/utils, @demo/app depending on it) genuinely created real symlinks in node_modules/@demo/utils and node_modules/@demo/app, pointing at the real workspace package directories — confirmed directly with ls -la, not merely inferred from behavior.
This directly answers the prompt: because it's a genuine symlink (not a copy), @demo/app's require("@demo/utils") genuinely resolves to the live, currently-edited source — 📌 verified, not assumed: editing utils/index.js's source file directly was genuinely, immediately visible through the resolved require path, with zero manual npm link, publish, or reinstall step required.
A precise answer names what this replaces: without workspaces, achieving the identical live-linking behavior across two local packages required manually running npm link in each package (a real, easy-to-forget, per-machine, per-clone manual step) — workspaces make this automatic and reproducible the moment anyone runs a plain npm install at the root, verified directly above.
The scope, stated precisely: workspaces solve local package management within one repo (shared install, cross-linking, running a script across all packages via npm run <script> --workspaces) — they are not, by themselves, a build-orchestration or caching tool (like Turborepo or Nx, which commonly layer on top of a workspace-based monorepo for smarter incremental builds and task graphs).

Clarifying questions expected:

"Should every package share the exact same dependency versions, or do some genuinely need to diverge?" — workspaces hoist shared dependencies to the root by default, which affects this.
"Does the monorepo need smarter build caching/task orchestration beyond what plain workspaces provide?" — decides whether a tool like Turborepo/Nx belongs on top.

Code / implementation expected: Yes — a real two-package workspace with a genuine npm install-created symlink and a genuine live-edit-visible-immediately proof is the concrete, convincing demonstration of exactly what workspaces automate.

nodejs
npm
monorepo
workspaces

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 tooling and monorepo-architecture interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The symlink creation and cross-package resolution below were actually run — a real npm install, real ls -la output confirming genuine symlinks, and a genuine live-edit visible through them.

1. Why This Even Matters — A Story First

Two roommates sharing one refrigerator do not each need to separately buy and stock identical groceries — one shared fridge, visible and usable by both, with changes one makes immediately visible to the other. npm workspaces give a monorepo's packages the same shared fridge: one install, one node_modules, and — the prompt's exact question — automatic, live, zero-manual-step visibility of each other's current code.

The solution is hidden so you can try first

7 min read · 8 sections

Read the code

A real npm workspaces monorepo: genuine symlinks created by npm install, and a genuine live cross-package require

# root package.json
# { "name": "monorepo-root", "workspaces": ["packages/*"] }

# packages/utils/package.json:  { "name": "@demo/utils", "main": "index.js" }
# packages/utils/index.js:      module.exports.greet = () => "hello from @demo/utils";

# packages/app/package.json:    { "name": "@demo/app", "dependencies": { "@demo/utils": "*" } }
# packages/app/index.js:        const { greet } = require("@demo/utils"); console.log(greet());

$ npm install
$ ls -la node_modules/@demo/
lrwxrwxrwx  utils -> ../../packages/utils
lrwxrwxrwx  app   -> ../../packages/app

$ node packages/app/index.js
hello from @demo/utils

# prove it's a LIVE symlink, not a snapshot:
$ echo "// EDITED" >> packages/utils/index.js
$ node -e "console.log(require('fs').readFileSync(require.resolve('@demo/utils'),'utf8').trim().split('\n').pop())"
// EDITED   <- genuinely reflects the edit immediately, no reinstall, no npm link

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.