Runs a script defined in the package's manifest file.
Let's say you have a
watch script configured in your
package.json, like so:
"watch": "webpack --watch"
You can now run that script by using
pnpm run watch! Simple, right? Otra cosa a tener en cuenta para aquellos a los que les gusta ahorrar pulsaciones de teclas y tiempo es que todos los scripts tienen un alias como comandos pnpm, por lo que, en última instancia,
pnpm watch es solo una abreviatura de
pnpm run watch (SÓLO para scripts que no comparten el mismo nombre que los comandos pnpm ya existentes).
PATH preexistente del shell,
pnpm run incluye
node_modules/.bin en el
PATH proporcionado a
scripts. Esto significa que siempre que tenga un paquete instalado, puede usarlo en un script como un comando normal. Por ejemplo, si tiene instalado
eslint, puede escribir un script así:
"lint": "eslint src --fix"
And even though
eslint is not installed globally in your shell, it will run.
<workspace root>/node_modules/.bin is also added to the
PATH, so if a tool is installed in the workspace root, it may be called in any workspace package's
By default, pnpm doesn't run arbitrary
post hooks for user-defined scripts (such as
prestart). This behavior, inherited from npm, caused scripts to be implicit rather than explicit, obfuscating the execution flow. It also led to surprising executions with
pnpm serve also running
If for some reason you need the pre/post scripts behavior of npm, use the
There are some environment variables that pnpm automatically creates for the executed scripts. These environment variables may be used to get contextual information about the running process.
These are the environment variables created by pnpm:
- npm_command - contains the name of the executed command. If the executed command is
pnpm run, then the value of this variable will be "run-script".
Any options for the
run command should be listed before the script's name. Options listed after the script's name are passed to the executed script.
All these will run pnpm CLI with the
pnpm run --silent watch
pnpm --silent run watch
pnpm --silent watch
Any arguments after the command's name are added to the executed script. So if
webpack --watch, then this command:
pnpm run watch --no-color
webpack --watch --no-color
- Default: null
- Type: path
The shell to use for scripts run with the
pnpm run command.
For instance, to force usage of Git Bash on Windows:
pnpm config set script-shell "C:\\Program Files\\git\\bin\\bash.exe"
- Default: false
- Type: Boolean
This option simplifies cross-platform scripting. For instance, by default, the next script will fail on non-POSIX-compliant systems:
"test": "NODE_ENV=test node test.js"
But if the
shell-emulator setting is set to
true, it will work on all platforms.
This runs an arbitrary command from each package's "scripts" object. If a package doesn't have the command, it is skipped. If none of the packages have the command, the command fails.
You can use the
--if-present flag to avoid exiting with a non-zero exit code when the script is undefined. This lets you run potentially undefined scripts without breaking the execution chain.
Completely disregard concurrency and topological sorting, running a given script immediately in all matching packages with prefixed streaming output. This is the preferred flag for long-running processes over many packages, for instance, a lengthy build process.
Stream output from child processes immediately, prefixed with the originating package directory. This allows output from different packages to be interleaved.
Aggregate output from child processes that are run in parallel, and only print output when the child process is finished. It makes reading large logs after running
pnpm -r <command> with
--parallel or with
--workspace-concurrency=<number> much easier (especially on CI). Only
--reporter=append-only is supported.
- Default: false
- Type: Boolean
true, pnpm will run any pre/post scripts automatically. So running
pnpm foo will be like running
pnpm prefoo && pnpm foo && pnpm postfoo.
Added in: v7.22.0
Resume execution from a particular project. This can be useful if you are working with a large workspace and you want to restart a build at a particular project without running through all of the projects that precede it in the build order.