pnpm recursive

Runs a pnpm command recursively on all subdirectories in the package or every available workspace

Subcommands

NameDescription
addInstalls a package and any packages that it depends on. By default, any new package is installed as a production dependency
install, iPnpm install is used to install all dependencies for a project. In a CI environment, installation fails if a lockfile is present but needs an update. Inside a workspace, pnpm install installs all dependencies in all the projects. If you want to disable this behavior, set the recursive-install setting to false
update, upgrade, upPnpm update updates packages to their latest version based on the specified range. When used without arguments, updates all dependencies. You can use patterns to update specific dependencies
remove, rm, uninstall, unRemoves packages from node_modules and from the project's package.json
unlinkUnlinks a system-wide package (inverse of pnpm link). If called without arguments, all linked dependencies will be unlinked. This is similar to yarn unlink, except pnpm re-installs the dependency after removing the external link
rebuild, rbRebuild a package
list, lsThis command will output all the versions of packages that are installed, as well as their dependencies, in a tree-structure. Positional arguments are name-pattern@version-range identifiers, which will limit the results to only the packages named. For example, pnpm list "babel-*" "eslint-*" semver@5
outdatedChecks for outdated packages. The check can be limited to a subset of the installed packages by providing arguments (patterns are supported)
whyShows all packages that depend on the specified package
run, run-scriptRuns a script defined in the package's manifest file
execExecute a shell command in scope of a project. node_modules/.bin is added to the PATH, so pnpm exec allows executing commands of dependencies
test, t, tstRuns an arbitrary command specified in the package's test property of its scripts object. The intended usage of the property is to specify a command that runs unit or integration testing for your program
publishPublishes a package to the registry. When publishing a package inside a workspace, the LICENSE file from the root of the workspace is packed with the package (unless the package has a license of its own). You may override some fields before publish, using the publishConfig field in package.json. You also can use the publishConfig.directory to customize the published subdirectory (usually using third party build tools). When running this command recursively (pnpm -r publish), pnpm will publish all the packages that have versions not yet published to the registry

Options

NameDescription
--link-workspace-packages <bool or `deep`>Link locally available packages in workspaces of a monorepo into node_modules instead of re-downloading them from the registry. This emulates functionality similar to yarn workspaces. When this is set to deep, local packages can also be linked to subdependencies. Be advised that it is encouraged instead to use npmrc for this setting, to enforce the same behaviour in all environments. This option exists solely so you may override that if necessary
--workspace-concurrency <<number>>Set the maximum number of tasks to run simultaneously. For unlimited concurrency use Infinity
--bailStops when a task throws an error
--no-bailDon't stop when a task throws an error
--sortPackages are sorted topologically (dependencies before dependents)
--no-sortDisable packages sorting
--reverseThe order of packages is reversed
--filter <Filepath / Package>Filtering allows you to restrict commands to specific subsets of packages. pnpm supports a rich selector syntax for picking packages by name or by relation. More details: https://pnpm.io/filtering