Runs a pnpm command recursively on all subdirectories in the package or every available workspace
|Installs a package and any packages that it depends on. By default, any new package is installed as a production dependency|
|Pnpm 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, up
|Pnpm 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, un
|Removes packages from node_modules and from the project's package.json|
|Unlinks 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 a package|
|This 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|
|Checks for outdated packages. The check can be limited to a subset of the installed packages by providing arguments (patterns are supported)|
|Shows all packages that depend on the specified package|
|Runs a script defined in the package's manifest file|
|Execute 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, tst
|Runs 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|
|Publishes 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|
--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|
|Set the maximum number of tasks to run simultaneously. For unlimited concurrency use Infinity|
|Stops when a task throws an error|
|Don't stop when a task throws an error|
|Packages are sorted topologically (dependencies before dependents)|
|Disable packages sorting|
|The 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|