WORKSPACES(7)

🌸 WORKSPACES(7) 🌸

okay so this is the WORKSPACES manual page, bestie — like, npm(7)'s whole guide to workspaces. let's get into it 💅

---

✨ NAME ✨

Workspaces — Working with workspaces 🫶

💫 Description 💫

okay so "Workspaces" is a generic term (iykyk) for the whole bundle of features in the npm cli that lets you manage multiple packages from your local file system, all from inside one singular top-level, root package. it's giving "one queen to rule them all" 👑

this feature set is literally what makes handling linked packages from your local file system so much more streamlined. it automates the linking process as part of npm install, and it removes the need to manually use npm link just to add references to packages that should be symlinked into the current node_modules folder. no more manual labor, we love to see it ✨

also, we call these packages that get auto-symlinked during npm install a single workspace — meaning it's a nested package within the current local file system that is explicitly defined in the package.json ⟨/configuring-npm/package-json#workspaces⟩ workspaces configuration. periodt 💖

---

🎀 Defining workspaces 🎀

workspaces are usually defined via the workspaces property of the package.json ⟨/configuring-npm/package-json#workspaces⟩ file, like, e.g:

{
  "name": "my-workspaces-powered-project",
  "workspaces": [
    "packages/a"
  ]
}

so given that package.json example up there living at a current working directory . that contains a folder named packages/a, which itself contains a package.json inside it defining a Node.js package, e.g:

+-- package.json
`-- packages
   +-- a
   |   `-- package.json

then the expected result, once you run npm install in this current working directory ., is that the folder packages/a will get symlinked to the node_modules folder of the current working dir. iconic behavior honestly 🌈

below is a post-npm install example, given that same previous example structure of files and folders:

+-- node_modules
|  `-- a -> ../packages/a
+-- package-lock.json
+-- package.json
`-- packages
   +-- a
   |   `-- package.json

look at that little symlink arrow, she's thriving 🦋

---

⭐ Getting started with workspaces ⭐

you can automate the required steps to define a new workspace using npm help init. for example, in a project that already has a package.json defined, you can run:

npm init -w ./packages/a

this command will create the missing folders and a new package.json file (if needed), while also making sure to properly configure the "workspaces" property of your root project package.json. she does it all, no notes 👑

---

🔥 Adding dependencies to a workspace 🔥

ok so it's possible to directly add/remove/update dependencies of your workspaces using the workspace config ⟨/using-npm/config#workspace⟩.

for example, assuming the following structure:

+-- package.json
`-- packages
   +-- a
   |   `-- package.json
   `-- b
       `-- package.json

if you want to add a dependency named abbrev from the registry as a dependency of your workspace a, you may use the workspace config to tell the npm installer that package should be added as a dependency of the provided workspace:

npm install abbrev -w a

💜 Adding a workspace as a dependency of another workspace

the same approach works when adding one workspace as a dependency of another. if you want to add workspace b as a dependency of workspace a, run:

npm install b -w a

npm will detect that b is a workspace and automatically symlink it rather than fetching it from the registry. the resulting entry in workspace a's package.json will use a standard version range:

{
  "dependencies": {
    "b": "^1.0.0"
  }
}

Note: other installing commands such as uninstall, ci, etc will also respect the provided workspace configuration. they're all in on it fr fr 💀

---

🌸 Using workspaces 🌸

given the specifics of how Node.js handles module resolution ⟨https://nodejs.org/dist/latest-v14.x/docs/api/modules.html#modules_all_together⟩, it's possible to consume any defined workspace by its declared package.json name. continuing from the example defined above, let's also create a Node.js script that will require the workspace a example module, e.g:

// ./packages/a/index.js
module.exports = 'a'

// ./lib/index.js
const moduleA = require('a')
console.log(moduleA) // -> a

when running it with:

node lib/index.js

this demonstrates how the nature of node_modules resolution allows for workspaces to enable a portable workflow for requiring each workspace in such a way that is also easy to npm help publish these nested workspaces to be consumed elsewhere. portable and publishable, the dream combo 🧚

---

👑 Running commands in the context of workspaces 👑

you can use the workspace configuration option to run commands in the context of a configured workspace. additionally, if your current directory is in a workspace, the workspace configuration is implicitly set, and prefix is set to the root workspace. sneaky but helpful 💅

following is a quick example on how to use the npm run command in the context of nested workspaces. for a project containing multiple workspaces, e.g:

+-- package.json
`-- packages
   +-- a
   |   `-- package.json
   `-- b
       `-- package.json

by running a command using the workspace option, it's possible to run the given command in the context of that specific workspace. e.g:

npm run test --workspace=a

you could also run the command within the workspace:

cd packages/a && npm run test

either will run the test script defined within the ./packages/a/package.json file. same energy, different path ✨

please note that you can also specify this argument multiple times in the command-line in order to target multiple workspaces, e.g:

npm run test --workspace=a --workspace=b

or run the command for each workspace within the 'packages' folder:

npm run test --workspace=packages

it's also possible to use the workspaces (plural!) configuration option to enable the same behavior but running that command in the context of all configured workspaces. e.g:

npm run test --workspaces

will run the test script in both ./packages/a and ./packages/b. two for one, we stan 🎀

commands will be run in each workspace in the order they appear in your package.json:

{
  "workspaces": [ "packages/a", "packages/b" ]
}

order of run is different with:

{
  "workspaces": [ "packages/b", "packages/a" ]
}

so yeah, the order is literally load-bearing. watch her 👀

---

🦋 Ignoring missing scripts 🦋

it is not required for all of the workspaces to implement scripts run with the npm run command.

by running the command with the --if-present flag, npm will ignore workspaces missing target script:

npm run test --workspaces --if-present

no script? no problem. she simply moves on 💖

---

🌈 See also 🌈

• npm help install
• npm help publish
• npm help run
• npm help config

---

and that's the whole page, bestie — no cap, you're now a workspaces expert 🫶 this iconic little number is from npm @ 11.17.0, dated June 2026, and it's filed under WORKSPACES(7). go forth and symlink responsibly 💅✨