# pnpm v12.0.0-rc.4 — pnpm 12 RC 4

- Product: pnpm (https://whatsnew.fyi/product/pnpm)
- Vendor: pnpm
- Date: 2026-08-12
- Version: v12.0.0-rc.4
- Original notes: https://github.com/pnpm/pnpm/releases/tag/v12.0.0-rc.4
- Permalink: https://whatsnew.fyi/product/pnpm/releases/v12.0.0-rc.4
- Labels: Pre-release

What's New is an index, not a publisher: every entry below links to the vendor's own release notes, which are the authoritative source. Entries are labelled where they are hand-curated sample data, pre-releases, or drawn from a secondary source such as a developer blog.

Reuse: the summaries, labels and curation here are © What's New. Quote freely with attribution and a link back; wholesale republication of the corpus is not permitted — terms: https://whatsnew.fyi/terms. The vendors' own release notes remain their publishers'.

---

- **added** — Add a new setting minimumReleaseAgeExcludePrune that prunes entries of minimumReleaseAgeExclude in pnpm-workspace.yaml when pnpm add, pnpm update, and pnpm remove are run
- **added** — Add support for the syncInjectedDepsAfterScripts setting to bring injected copies of packages back in step with their source after specified scripts run
- **changed** — Rename cleanupUnusedCatalogs to catalogPrune for consistent vocabulary between catalog and release-age exclude pruning
- **changed** — pnpm add no longer re-resolves the dependency graph when pnpm-lock.yaml already holds a satisfying version
- **changed** — Global installs now switch over atomically by moving a stable per-package link instead of rewriting every shim
- **fixed** — pnpm audit --fix no longer adds minimumReleaseAgeExclude entries for patched versions published before the minimumReleaseAge cutoff
- **fixed** — Bound the number of requests in flight to the .pnpmfile.cjs worker process to prevent timeouts on large installs
- **fixed** — pnpm add and pnpm update under catalogMode: strict no longer fail when the catalog entry is a range that the wanted version satisfies
- **fixed** — pnpm install in CI now uses frozen lockfile mode by default when an existing pnpm-lock.yaml is non-empty
- **fixed** — A changed catalogs or pnpm.overrides block no longer requires being the only change for pnpm install to update the lockfile in place
- **fixed** — pnpm install now updates the lockfile in place when several kinds of changes happened since the last install
- **changed** — Resolving peer dependencies in a workspace with many peer-dependency cycles now requires less than half the memory and finishes about twice as fast
- **fixed** — pnpm install and pnpm dedupe no longer consume all available memory when resolving a graph with many packages declaring the same missing peer dependency
- **fixed** — With dedupeDirectDeps, redundant project symlinks are removed on the next install instead of surviving forever

##### Minor Changes

- Added a new setting `minimumReleaseAgeExcludePrune`. When enabled, `pnpm add`, `pnpm update`, and `pnpm remove` prune the entries of `minimumReleaseAgeExclude` in `pnpm-workspace.yaml` that the freshly written lockfile no longer resolves: versions that are gone are dropped (an entry is removed once none of its versions remain), and entries for packages that are no longer in the lockfile are removed too. Name patterns (`@scope/*`) are always kept. The cleanup is skipped when the install's lockfile does not cover the whole workspace (`sharedWorkspaceLockfile: false`), since entries another project still needs would look stale.

  Renamed `cleanupUnusedCatalogs` to `catalogPrune`, so that catalog pruning and release-age exclude pruning use one vocabulary. `cleanupUnusedCatalogs` continues to work; when both are set, `catalogPrune` wins.

- Added support for the `syncInjectedDepsAfterScripts` setting. It names the scripts after which every injected copy of the package that ran them is brought back in step with its source, so a build script no longer leaves the copies in the virtual store holding stale files.

##### Patch Changes

- `pnpm add` no longer re-resolves the dependency graph when `pnpm-lock.yaml` already holds a version satisfying the request — promoting a transitive dependency to a direct one, or adding to a second workspace package what a first one already depends on, now only saves the dependency in `package.json` and records its importer entry. A satisfying locked version is necessary but not sufficient: the install still falls back to a full resolution for a dist tag, an alias, a `workspace:`/`catalog:`/git/tarball specifier, `--save-peer`, an overridden package, a `catalogMode` other than `manual`, and — under `resolutionMode: time-based` or `lowest-direct`, which resolve a direct dependency to the low end of its range — a range several locked versions satisfy.

- Global installs now switch over atomically. The command shims in the global bin directory point at a stable per-package link rather than at the directory a particular install produced, so `pnpm add -g` and `pnpm update -g` activate a new version by moving that one link instead of rewriting every shim. A command can no longer be missing from `PATH` while an install is in progress, and a failed install leaves the previous version in place.

- `pnpm audit --fix` and `pnpm audit --fix update` no longer add `minimumReleaseAgeExclude` entries for patched versions that were published before the `minimumReleaseAge` cutoff. The publish time of each minimum patched version is now checked against the registry metadata, and only versions young enough to be blocked by the age gate get an exclusion entry [#11563](https://github.com/pnpm/pnpm/issues/11563).

- Bounded the number of requests in flight to the `.pnpmfile.cjs` worker process. An install that runs the `readPackage` hook for thousands of packages at once no longer risks failing with `ERR_PNPM_PNPMFILE_FAIL` on a hook timeout spent waiting in the queue rather than running the hook, and holds fewer copies of the manifests it is hooking while it waits.

- `pnpm add <pkg>@<version>` and `pnpm update <pkg>@<version>` under `catalogMode: strict` no longer fail with `ERR_PNPM_CATALOG_VERSION_MISMATCH` when the catalog entry is a range that the wanted version satisfies. The dependency keeps using the catalog; only a version that really falls outside the catalog's range is rejected [#13715](https://github.com/pnpm/pnpm/issues/13715).

- Fixed `pnpm install` in CI to use frozen lockfile mode by default when an existing `pnpm-lock.yaml` is non-empty. An outdated lockfile now fails without being rewritten, while projects without a lockfile or with an empty lockfile can still generate one.

- A changed `catalogs` or `pnpm.overrides` block no longer has to be the only change for `pnpm install` to update the lockfile in place. Editing an override while also removing a dependency,

_[Truncated at 4000 characters — full notes: https://github.com/pnpm/pnpm/releases/tag/v12.0.0-rc.4]_