NPM-RUN-SCRIPT(1)
π NAME π</p>
npm-run-script β run arbitrary package scripts, bestie. That's it, that's the whole vibe. This page is the NPM-RUN-SCRIPT(1) manual, and it's lowkey one of the most useful ones in the whole npm family. π«Ά
β¨ Synopsis β¨
npm run-script <command> [-- <args>]
aliases: run, rum, urn π
πΈ Description πΈ
okay so. This runs an arbitrary command out of a package's "scripts" object. That's the entire point of it. If you don't hand it a "command", it will just list the available scripts for you β which, honestly, is the move when you roll up to a new repo and need the lay of the land. π
run[-script] is what test, start, restart, and stop use under the hood, but you can also just call it directly yourself. When npm prints out the scripts in the package, it separates them into lifecycle (test, start, restart) and directly-run scripts. So you can see which ones are ~special~. β¨
Any positional arguments get passed straight to the script you specified. And here's the trick: use -- to pass --prefixed flags and options that npm would otherwise gobble up and parse for itself. Not me being dramatic, it's genuinely important. π
For example:
npm run test -- --grep="pattern"
And listen: those arguments only go to the script specified after npm run. They do not get passed to any pre or post script. Just the one. periodt. π
The env script is a special built-in command that lists environment variables that will be available to the script at runtime. And if you've defined your own "env" command in your package, it takes precedence over the built-in one β your version wins, queen. π
In addition to the shell's pre-existing PATH, npm run adds node_modules/.bin to the PATH provided to scripts. So any binaries from locally-installed dependencies can be used without the node_modules/.bin prefix. Like, if you have a devDependency on tap in your package, you should write:
"scripts": {"test": "tap test/*.js"}
instead of
"scripts": {"test": "node_modules/.bin/tap test/*.js"}
so much cleaner, we love a shorter path. π
The actual shell your script runs inside is platform dependent. By default, on Unix-like systems it's the /bin/sh command, and on Windows it's cmd.exe. And plot twist: the actual shell that /bin/sh refers to also depends on the system. You can customize the shell with the script-shell config β¨/using-npm/config#script-shellβ©. π
Scripts are run from the root of the package folder, no matter what your current working directory is when you call npm run. If you want your script to behave differently depending on what subdirectory you're in, use the INIT_CWD environment variable β it holds the full path you were in when you ran npm run. π§
npm run sets the NODE environment variable to the node executable that npm itself is executed with. cute, right?
And one more thing: if you try to run a script without having a node_modules directory and it fails, you'll get a warning telling you to run npm install β just in case you forgot. which, bestie, you probably did. π
π¦ Workspaces support π¦
You can use the workspace β¨/using-npm/config#workspaceβ© or workspaces β¨/using-npm/config#workspacesβ© configs to run an arbitrary command from a package's "scripts" object in the context of the specified workspaces. And if no "command" is provided, it will list the available scripts for each of those configured workspaces. multi-slaying. π₯
Given a project with configured workspaces, e.g:
+-- package.json
`-- packages
+-- a
| `-- package.json
+-- b
| `-- package.json
`-- c
`-- package.json
Assuming the workspace configuration is properly set up at the root level package.json file. e.g:
{
"workspaces": [ "./packages/*" ]
}
And assuming each of the configured workspaces has a configured test script, we can run tests in all of them using the workspaces config β¨/using-npm/config#workspacesβ©:
npm test --workspaces
π Filtering workspaces π
It's also possible to run a script in a single workspace using the workspace config along with a name or directory path:
npm test --workspace=a
The workspace config can also be specified multiple times, so you can run a specific script in the context of multiple workspaces at once. And when you're defining values for the workspace config on the command line, you can also use -w as a shorthand, e.g:
npm test -w a -w b
That last command runs test in both the ./packages/a and ./packages/b packages. no cap. π
π Configuration π
workspace
- Default: (empty)
- Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the current project, while filtering down to only the workspaces defined by this configuration option.
Valid values for the workspace config are either:
- Workspace names
- Path to a workspace directory
- Path to a parent workspace directory (this will result in selecting all workspaces within that folder)
When it's set for the npm init command, this may be set to the folder of a workspace that doesn't exist yet β so npm creates the folder and sets it up as a brand new workspace within the project. glow-up in real time. β¨
This value is not exported to the environment for child processes.
workspaces
- Default:
null - Type: null or Boolean
Set it to true to run the command in the context of all configured workspaces.
Explicitly setting this to false will cause commands like install to ignore workspaces altogether. When it's not set explicitly:
- Commands that operate on the
node_modulestree (install,update, etc.) will link workspaces into thenode_modulesfolder. - Commands that do other things (
test,exec,publish, etc.) will operate on the root project, unless one or more workspaces are specified in theworkspaceconfig.
This value is not exported to the environment for child processes.
include-workspace-root
- Default:
false - Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When it's false, specifying individual workspaces via the workspace config β or all workspaces via the workspaces flag β causes npm to operate only on the specified workspaces, and not on the root project. sorry root, you're sitting this one out. π
This value is not exported to the environment for child processes.
if-present
- Default:
false - Type: Boolean
If true, npm will not exit with an error code when run-script is invoked for a script that isn't defined in the scripts section of package.json. This option is your girl when it's desirable to optionally run a script when it's present, and fail if the script fails. Super useful, for example, when running scripts that may only apply for some builds in an otherwise generic CI setup. π§
This value is not exported to the environment for child processes.
ignore-scripts
- Default:
false - Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script β such asnpm start,npm stop,npm restart,npm test, andnpm run-scriptβ will still run their intended script ifignore-scriptsis set, but they will not run any pre- or post-scripts. so like, the main character still shows up, the entourage does not. π
foreground-scripts
- Default:
falseunless when usingnpm packornpm publishwhere it defaults totrue - Type: Boolean
Run all build scripts (ie, preinstall, install, and postinstall) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
Heads up: this will generally make installs run slower, and be much noisier β but it can be useful for debugging. chaotic but informative, honestly iconic. π₯
script-shell
- Default:
'/bin/sh'on POSIX systems,'cmd.exe'on Windows - Type: null or String
The shell to use for scripts run with the npm exec, npm run and npm init <package-spec> commands. π
β See Also β
npm help scriptsnpm help testnpm help startnpm help restartnpm help stopnpm help confignpm help workspaces
and that's the whole page, bestie!! π this was NPM@10.9.8, dated March 2026 β go forth and npm run something, you've got this. π
β¨π¦
π¦ where this page comes from
- centos-stream 10: nodejs-npm 1:10.9.8-1.22.23.2.1.el10 Β· Apache-2.0 AND Artistic-2.0 AND BSD-2-Clause AND BSD-3-Clause AND BlueOak-1.0.0 AND CC-BY-3.0 AND CC0-1.0 AND ISC AND MIT
- centos-stream 9: npm 1:10.9.8-1.22.23.2.1.module_el9+1435+a086d799 Β· Apache-2.0 AND Artistic-2.0 AND BSD-2-Clause AND BSD-3-Clause AND BlueOak-1.0.0 AND CC-BY-3.0 AND CC0-1.0 AND ISC AND MIT
- fedora 44: nodejs22-npm 1:10.9.8-1.22.23.1.2.fc44 Β· Apache-2.0 AND Artistic-2.0 AND BSD-2-Clause AND BSD-3-Clause AND BlueOak-1.0.0 AND CC-BY-3.0 AND CC0-1.0 AND ISC AND MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms