pnpm update

Псевдоніми: up, upgrade

pnpm update оновлює пакунки до своєї останньої версії на основі зазначеного діапазону.

Якщо використовується без аргументів, оновлює всі залежності.

TL;DR#

Команда Значення
pnpm up Оновлює всі залежності, дотримуючись діапазонів, вказаних у package.json
pnpm up --latest Оновлює всі залежності до їх останніх версій
pnpm up foo@2 Оновлює foo до останньої версії у v2
pnpm up "@babel/*" Оновлює всі залежності в межах @babel

What an update writes#

Besides moving pnpm-lock.yaml to the newly resolved versions, pnpm update writes the new range back to the place the dependency is declared:

  • In package.json, the range is moved onto the resolved version while the operator the dependency already declared is kept, so ^1.1.0 stays a caret range.
  • A dependency declared through the catalog: protocol is not rewritten in package.json. The catalog entry it points at is updated instead, in pnpm-workspace.yaml.
  • A dependency declared through the jsr: protocol keeps its jsr: prefix, and its range moves like an npm range.
  • A dependency declared through a dist-tag, such as "foo": "latest", keeps tracking the tag. The tag stays in package.json and only the lockfile moves to the version behind it, with --latest as well.
  • Since v12.12.0, a config dependency is updated too, and its new range is written to pnpm-workspace.yaml.
  • A runtime (node, deno, bun declared in devEngines.runtime, engines.runtime, or through the runtime: / tool: protocol) and a package manager (pnpm, npm, yarn, bun declared in devEngines.packageManager or packageManager) are updated too, and their new versions or ranges are written back to package.json (and pnpm-lock.yaml when the pin is recorded there).
  • When cargo.enabled is true, Cargo dependencies in Cargo.toml and Cargo.lock are updated too. Pass crate:<name> (or crate:<name>@<req>) to target specific crates.
  • When python.enabled is true, Python dependencies in pyproject.toml and pylock.toml are updated too. Pass pypi:<name> (or pypi:<requirement>) to target specific Python distributions.
  • Since v12.6.0, 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.

Pass --no-save to update the lockfile only and leave the declared ranges alone.

Since v12.0.0, --patches does something different from all of this: it changes no version and no declared range, refreshing only which registry artifact each locked version resolves to. That still rewrites lockfile metadata (the integrity, the revision, and the package snapshot around them), because artifact revisions may declare different dependencies. See Registry revisions.

Updating to a specific version#

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.

Вибір залежностей з шаблонами#

Ви можете використовувати шаблони для оновлення певних залежностей.

Оновити всі пакунки babel:

pnpm update "@babel/*"

Оновити всі залежності, крім webpack:

pnpm update "\!webpack"

Шаблони також можна комбінувати, тому наступна команда оновить усі пакунки babel, крім core:

pnpm update "@babel/*" "\!@babel/core"

Updating GitHub Actions#

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 v12.3.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.

Параметри#

--recursive, -r#

Одночасно виконується оновлення всіх вкладених тек з package.json (за виключенням node_modules).

Приклад використання:

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

--depth <number>#

  • Default: Infinity
  • Тип: Number

How deep in the dependency tree to update. 0 updates direct dependencies only.

--latest, -L#

Оновлює залежності до їхньої останньої стабільної версії, визначеної теґами latest (потенційно оновлюємо пакунки до основних версій), якщо діапазон версій, вказаний у package.json, є меншим за теґ latest (тобто, це не призведе до пониження версій пре-випусків).

Since v12.6.0, --latest does not move a dependency past a specifier supplied by packageExtensions, a readPackage hook, or an override. The lockfile stays inside that specifier.

A Cargo requirement keeps its operator when updated, so ~1.0 becomes ~1.1 and =1.0.0 stays exact. A requirement with only an upper bound, such as <2, is kept while the new version matches it, and becomes a caret requirement, such as ^2.0.0, when --latest moves past it. A requirement in the selector, as in pnpm update crate:foo@^2, replaces it. savePrefix and saveExact apply only to new Cargo dependencies. Saved Cargo requirements omit build metadata.

A Python requirement keeps its operator and precision too, so ~=1.0 becomes ~=2.0 and ==1.* becomes ==2.*. A requirement with only an upper bound, such as <2, or with several clauses, such as >=1.0,<2, becomes >=2.0 when --latest moves past it. A selected pre-release that the requirement does not name, such as 1.4rc1 for ==1.*, adds a clause that names it, as in ==1.*,>=1.4rc1. savePrefix and saveExact do not apply to Python requirements.

--patches#

Added in: v12.0.0

Refresh registry revisions without changing any package version: for every locked registry package, pnpm resolves current metadata for the same name@version, and adopts the artifact the registry selects now if that changed. Versions and declared ranges are left alone, but the lockfile entry is rewritten as a whole (integrity, revision, and the package snapshot around them), since revisions may declare different dependencies.

Cannot be combined with package selectors, --latest, --interactive, or --global (ERR_PNPM_PATCHES_WITH_SELECTOR).

--pnpr-server <url>#

Added in: v12.0.0

Offload the resolution of a --patches refresh to a pnpr server, the way pnprServer does for an install.

--global, -g#

Оновлює глобальні пакунки. 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#

Намагається зробити звʼязки для усіх пакунків у робочому просторі. Версії оновлюються відповідно до версій пакунків у робочій області.

Якщо певні пакунки буде оновлено, команда не виконається, якщо жодної з оновлених залежностей не буде знайдено у робочому просторі. Наприклад, така команда не виконається, якщо express не є пакунком робочої області:

pnpm up -r --workspace express

--prod, -P, --production#

Оновлює пакунки лише в dependencies та optionalDependencies.

--dev, -D#

Оновлює лише пакунки в devDependencies.

--no-optional#

Не оновлювати пакунки в optionalDependencies.

--optional#

Only update packages in optionalDependencies.

--peer#

Also update packages in peerDependencies. It cannot be combined with --interactive (ERR_PNPM_INTERACTIVE_PEER_UNSUPPORTED).

--save-exact, -E#

With --latest, write the resolved version to package.json without a range operator.

--lockfile-only#

Update pnpm-lock.yaml without downloading dependencies or changing node_modules.

--lockfile-dir <dir>#

The directory in which pnpm-lock.yaml is created. It cannot be combined with --global.

--interactive, -i#

Показати застарілі залежності та вибрати, які з них оновити.

For a package from a registry declared with serverType: pnpr, the release notes between the installed and the offered version are shown below the list while the package is under the cursor.

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#

Не оновлювати діапазони в package.json.

--changeset#

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.

--no-changeset#

Don't write a change intent, even when update.changeset is true.

--include-github-actions#

Also update the GitHub Actions referenced by the repository's workflow files. See Updating GitHub Actions.

Supply-chain policy flags#

Added in: v12.3.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.

--cpu, --os, --libc, --ignore-scripts, --ignore-pnpmfile#

These work as they do for pnpm install.

--filter <package_selector>#

Читайте більше про фільтрування.