Zoltan Kochan
cb3f29bc0a
Part of pnpm/tasks#191. Wrong claims, fixed in the v12 docs and, where the same text is wrong for v11, in the v11 docs: - logout: drop the nonexistent --scope option. - patch: the edit dir is node_modules/.pnpm_patches/<name>@<version>; drop the "*" special case. - patch-commit: fix the ---patches-dir heading. - prefix: describe the real marker walk instead of "closest package.json". - setup: setup installs pnpm as a global package and writes pn/pnpx/pnx. - start, test: "run start" and "run test" are not aliases. - unlink: drop the system-wide and link --global wording. - unpublish: a package name is required; --otp has no env var; --registry wording. - update: --depth is dependency depth, not directory depth. - version: --tag-version-prefix defaults to the tagVersionPrefix setting. - view: the first argument is always the package. - why: drop --global and --only-projects; --exclude-peers has no effect; --prod includes optionalDependencies. - install: recursiveInstall spelling; replace the stale ci-info snippet. - v12 only: pack-app runtime default and builder download, pnx provisioning list and cmd.exe typo, tasks sample priority. Missing flags, settings, and error codes on the v12 pages: install (about twenty flags), lane, licenses, link, list, outdated, owner, pack-app path rules, pack, patch, patch-remove, peers, permissions, ping, pipeline, pm, pnx, prune, publish, rebuild, recursive, remove, repo, root, run, runtime, sbom, search, self-update, set-script, setup, shim, stage, star, start, store, tasks, team, test, token, unlink, unpublish, update, version, view, why, with. Stale history on the v12 pages: removed "Added in" markers older than v12 and rewrote "Since v11.x" and "In v11" sentences as current behavior (login, logout, licenses, link, outdated, patch, pnx, publish, runtime, sbom, self-update, setup, update, and others). Review follow-up: patch's default edit directory is named after the argument as typed (both versions); self-update installs the unscoped package only for pnpm 12 and newer; only --no-bail is restricted; npm_package_* covers name, version, config, engines and bin; prefix -g prints the parent of root -g; --optional no longer claims to override --no-optional.
7.3 KiB
id, title
| id | title |
|---|---|
| update | pnpm update |
Aliases: up, upgrade
pnpm update updates packages to their latest version based on the specified
range.
When used without arguments, updates all dependencies.
TL;DR
| Command | Meaning |
|---|---|
pnpm up |
Updates all dependencies, adhering to ranges specified in package.json |
pnpm up --latest |
Updates all dependencies to their latest versions |
pnpm up foo@2 |
Updates foo to the latest version on v2 |
pnpm up "@babel/*" |
Updates all dependencies under the @babel scope |
Since v11.27.1, a dependency whose specifier comes from a packageExtensions entry, a readPackage hook, or an override is not written to package.json. The lockfile keeps that specifier. pnpm update and pnpm audit --fix=update still move it inside the range.
An exact pin from one of those sources is left as it is. When that pin is a vulnerable version, pnpm audit --fix=update warns and points at pnpm audit --fix, which writes an override. An override is applied after packageExtensions and readPackage, so it replaces a specifier those supply.
Updating to a specific version
Since v11.23.0, pnpm update <name>@<version> fails with ERR_PNPM_UPDATE_VERSION_ON_INDIRECT_DEP when the package is not a direct dependency of any selected project. There is nowhere to record the version in that case; pin a transitive dependency through overrides instead. Ranges and tags are unaffected.
Selecting dependencies with patterns
You can use patterns to update specific dependencies.
Update all babel packages:
pnpm update "@babel/*"
Update all dependencies, except webpack:
pnpm update "\!webpack"
Patterns may also be combined, so the next command will update all babel packages, except core:
pnpm update "@babel/*" "\!@babel/core"
Updating GitHub Actions
Added in: v11.16.0
pnpm outdated can check the GitHub Actions referenced by the repository's workflow files for updates, and pnpm update can update them. This is opt-in for every command: pass --include-github-actions, or set update.githubActions to true in pnpm-workspace.yaml to enable it by default.
Updated actions are pinned to exact commit hashes, with their release tags preserved in comments:
- uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
Local actions are followed rather than looked up: a ./-relative reference, and
since v11.26.0 GitHub's self-repository spelling
(uses: $/.github/actions/setup), resolve inside the repository.
Checking for updates runs git ls-remote against every referenced repository. Actions whose refs cannot be read (for example, an action in a private repository) are skipped with a warning. If the actions are hosted on a different GitHub server (such as a GitHub Enterprise Server), set update.githubActionsServer (added in v11.17.0).
Options
--recursive, -r
Concurrently runs update in all subdirectories with a package.json (excluding
node_modules).
Usage examples:
pnpm --recursive update
# updates direct dependencies only
pnpm --recursive update --depth 0
# update typescript to the latest version in every package
pnpm --recursive update typescript@latest
--latest, -L
Update the dependencies to their latest stable version as determined by their latest tags (potentially upgrading the packages across major versions) as long as the version range specified in package.json is lower than the latest tag (i.e. it will not downgrade prereleases).
Since v11.27.1, --latest does not move a dependency past a specifier supplied by packageExtensions, a readPackage hook, or an override. The lockfile stays inside that specifier.
--global, -g
Update global packages. Packages from the pnpm 10 global layout are migrated to the current layout. After a successful migration, pnpm removes the old installation and its symlinks, shims, and hard-linked executables from PNPM_HOME.
--workspace
Tries to link all packages from the workspace. Versions are updated to match the versions of packages inside the workspace.
If specific packages are updated, the command will fail if any of the updated
dependencies are not found inside the workspace. For instance, the following
command fails if express is not a workspace package:
pnpm up -r --workspace express
--prod, -P
Only update packages in dependencies and optionalDependencies.
--dev, -D
Only update packages in devDependencies.
--no-optional
Don't update packages in optionalDependencies.
--peer
Added in: v11.28.0
Also update the ranges in peerDependencies. Without this flag, pnpm update leaves peerDependencies unchanged.
pnpm update --peer react
--interactive, -i
Show outdated dependencies and select which ones to update.
Since v11.21.0, combined with --global, each isolated install group is presented as one selectable item: packages that share a global installation update together as a unit.
--no-save
Don't update the ranges in package.json.
--changeset
Added in: v11.16.0
After the update completes, write a change intent (a changesets-compatible .changeset/*.md file) declaring a patch bump for every workspace package whose dependencies or optionalDependencies were changed by the update, and a major bump when its peerDependencies changed. Packages that consume an updated catalog entry via the catalog: protocol are included. Private packages, packages without a name, and packages listed in the ignore array of .changeset/config.json are skipped. If .changeset/config.json does not exist, a warning is printed and no changeset is generated.
Set update.changeset to true in pnpm-workspace.yaml to enable this behavior by default, and use --no-changeset to override the setting for one update.
--include-github-actions
Added in: v11.16.0
Also update the GitHub Actions referenced by the repository's workflow files. See Updating GitHub Actions.
Supply-chain policy flags
Added in: v11.26.0
pnpm update accepts the same policy overrides as pnpm install and pnpm add: --trust-lockfile, --no-trust-lockfile, --trust-policy, --trust-policy-exclude, and --trust-policy-ignore-after, so a policy can be relaxed or tightened for a single run without editing pnpm-workspace.yaml.