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

- Product: pnpm (https://whatsnew.fyi/product/pnpm)
- Vendor: pnpm
- Date: 2026-08-15
- Version: v12.0.0-rc.6
- Original notes: https://github.com/pnpm/pnpm/releases/tag/v12.0.0-rc.6
- Permalink: https://whatsnew.fyi/product/pnpm/releases/v12.0.0-rc.6
- 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 pnpm cache path command to print the directory pnpm uses for its metadata cache, including the lockfile verification log
- **added** — pnpm now installs other package managers (npm, Yarn Classic, Yarn Berry, Yarn 6, and Bun) with each resolved and fetched through trusted package-manager registries and verified against npm's signature before execution
- **added** — Git-hosted dependencies are now prepared with the package manager they request via packageManager or devEngines.packageManager pin
- **added** — Add pnpm dlx support for running other package managers and runtimes as single commands, such as pnx yarn@4 install, pnx npm@11 ci, and pnx bun@1.3.0 install
- **added** — Add pnpm shim commands (shim add, shim rm, shim ls) to manage command shims for any package
- **changed** — Globally installed package managers now follow a project's pin the same way a globally installed Node.js follows devEngines.runtime
- **changed** — pnpm add follows the same rule about what a name means, so pnpm add -g yarn@4 installs Yarn Berry and pnpm add -g node@22 installs that Node.js release
- **changed** — Naming a package manager in pnpm add records which one the project uses instead of installing it as a dependency
- **changed** — Resolving a Node.js runtime version is now much faster with per-version release metadata cached in the pnpm cache directory after signature verification
- **changed** — An exact stable Node.js version no longer downloads the Node.js release index
- **changed** — A pinned runtime whose metadata was fetched once resolves without any network access
- **fixed** — Corepack can now run pnpm 12 by shipping bin/pnpm.mjs and bin/pnpx.mjs entry points that fetch and verify the pinned native binary on first use

##### Minor Changes

- Added `pnpm cache path`, which prints the directory pnpm uses for its metadata cache. CI setups can use it to cache that directory — including the lockfile verification log, which lets a job skip re-checking an unchanged lockfile against the configured supply-chain policies.

- pnpm installs the other package managers now, not just itself: npm, Yarn Classic, Yarn Berry, Yarn 6 (`yarnpkg/zpm`), and Bun. Each is resolved and fetched through the trusted package-manager registries, and an npm-published one is verified against npm's signature for its exact version before it is executed.

  Three things use it:

  - A git-hosted dependency is prepared with the package manager it asks for. Its `packageManager` / `devEngines.packageManager` pin is honored, and a `yarn.lock` written by Yarn Classic no longer gets installed by Yarn Berry. pnpm provides that package manager when the dependency pinned a version, or when the host cannot satisfy what the dependency needs — so a repository built with Yarn now installs on a machine that has only pnpm, while a host that already has a suitable one keeps using its own.
  - `pnpm dlx` (`pnx`) runs one of them for a single command: `pnx yarn@4 install`, `pnx npm@11 ci`, `pnx bun@1.3.0 install`. Naming a package manager, or a runtime (`node`, `deno`, `bun`), there now provisions the real thing instead of installing the npm package that shares its name — unless the specifier locates a package rather than asking for a released version (`pnx yarn@npm:yarn@1.22.22`, `pnx yarn@yarnpkg/berry`), which installs what it names — `pnx yarn@4` was previously a missing version, since Yarn 4 is published as `@yarnpkg/cli-dist`, and `pnx node@22` now runs that Node.js release rather than a wrapper that downloads one. `--package` naming a package manager picks which of its commands to run, so `pnx --package npm@11 npx create-something` runs that npm's `npx`.
  - `pnpm shim add yarn` links a `yarn` command that runs whatever version the current project pins, and `pnpm shim rm` / `pnpm shim ls` manage those shims. It works for any package, not only package managers. Shims are never created as a side effect of `pnpm setup` or an install — a shim shadows the rest of your `PATH`, so pnpm only writes one when asked.

  Installing a package manager globally (`pnpm add -g yarn`) now makes it follow a project's pin too, the way a globally installed Node.js already follows `devEngines.runtime`: the pinned version runs where a project pins one, and the globally installed copy is the fallback everywhere else. An explicit `globalShims` entry, including `false`, is left as you set it.

  `pnpm add` follows the same rule about what a name means. `pnpm add -g yarn@4` installs Yarn Berry — it used to fail, because npm's `yarn` package stops at Classic — and `pnpm add -g node@22` / `pnpm add -g deno@2` install that Node.js or Deno release rather than a wrapper package that downloads one. In a project, naming a package manager records which one the project uses instead of installing it as a dependency, and naming a runtime records it under `engines.runtime` as `node@runtime:22` already did.

  The declaration goes where the package manager reads it. Yarn is started from a project pin by corepack, which reads only `packageManager` and only accepts an exact version there, so `pnpm add yarn@4` resolves the line and writes `"packageManager": "yarn@4.18.0"` — the same thing `corepack use yarn@4` writes, down to the `+sha512.…` integrity for the Yarn Classic line that corepack pins its tarball with. Every other package manager is recorded in `devEngines.packageManager`, which holds a range. Only one of the two fields is ever left behind: they declare the same thing, and corepack refuses to run a project whose declarations disagree.

  A JavaScript package manager on a machine without Node.js gets a managed LTS runtime to run on.

  What changes for a project coming from v11: `pnpm add yarn` recor

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