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

01

Understand 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.

nodejsnpmmonorepoworkspaces

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 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

Solution ready — 2 min read

Classified // press E to declassify

04

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

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

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