pnpm 12 is now available, and its most important change isn’t the Rust rewrite by itself: it’s that installs should be easier to reproduce across machines, CI runners, and large workspaces.
The version was released on August 26, 2026 as v12.0.0. The project presents pnpm 12 as stable, with the same general model of commands, configuration, and lockfile as pnpm 11, but with several behavior changes that matter for teams that care about the determinism of their builds.
The short version: git dependencies are canonicalized, peer dependency cycles are resolved deterministically, unknown workspace settings can fail instead of being silently ignored, global shims can follow project pins, and pnpm can provision other package managers instead of assuming they already exist on the machine.
That’s not a cosmetic release of a package manager. It touches CI reproducibility.
What is pnpm 12?
pnpm 12 is the new major stable version of pnpm, rewritten in Rust but designed to keep pnpm’s daily workflow familiar.
That matters because “rewritten in Rust” can sound like a migration warning. In this case, the practical story is more limited. The release notes say that the lockfile format and normal usage remain compatible enough that existing lockfiles continue to work, including frozen installs.
The interesting changes are around resolution behavior: how pnpm records git dependencies, how it handles peer cycles, how it validates workspace settings, and how it chooses binaries for runtimes or package managers within a project.
For a small app, pnpm 12 might feel like a normal update. For a monorepo, a CI fleet, or a team that pins versions of Node, Yarn, Bun, or pnpm per project, it deserves careful review.
How do I install pnpm 12?
You can install pnpm 12 through pnpm’s official installation paths, but as of August 29, 2026 the channel matters.
pnpm’s installation documentation says that latest on npm still points to the pnpm 11 line, so pnpm 12 installs from the next-12 tag. If you already have pnpm v11.10.0 or higher, the documented path is:
pnpm self-update next-12
If you don’t have pnpm installed yet, the documentation shows:
npx get-pnpm next-12
For the standalone installer on POSIX systems, the documentation shows:
curl -fsSL https://get.pnpm.io/install.sh | env PNPM_VERSION=next-12 sh -
```This is the first practical warning: don't copy an old generic installation command and assume it gives you pnpm 12. At the time of writing this note, Homebrew, winget, Scoop, and Chocolatey also appear documented as channels that still don't offer pnpm 12.
That's going to age fast, so treat the installation channel as a dated statement. Before changing CI images or onboarding documentation, check the official installation page again.
## What changes in pnpm 12 lockfiles?
pnpm 12 makes lockfiles more deterministic when dependency graphs contain peer dependency cycles.
The release notes describe a previous source of noise: when packages formed cycles during peer resolution, the final lockfile could depend on the order in which pnpm traversed the graph. That meant the same dependency graph could produce different lockfiles after changing the order of importers, dependencies, or resolution.
In pnpm 12, the members of each cycle are ordered canonically by package id, and the edge that closes the cycle is always cut in the same place.
The release phrase worth remembering is this: "lockfile is a pure function of the dependency graph".
That's exactly the kind of phrase CI teams want to hear. If two developers resolve the same dependency graph, or if a CI runner re-resolves after a dependency change, the lockfile shouldn't change just because the traversal order was different.
There's a practical note: existing lockfiles still work. Frozen installs consume them unchanged. The first install that actually re-resolves may reindex variants of peers that previously depended on traversal order.
So the migration question isn't "does my lockfile break immediately?". It's "when we re-resolve dependencies, are we ready to review a one-time lockfile normalization?".
## What changes with git dependencies?
pnpm 12 treats git dependencies on known hosts as repository identities, not as transport choices.
For GitHub, GitLab, and Bitbucket, different ways of naming the same repository now resolve via the host's canonical HTTPS URL. That includes short forms, HTTPS forms, and SSH-style specifiers. The lockfile should no longer record SSH URLs for those known hosts.
The reason is practical: pnpm could previously probe the network and record a transport that worked on one machine but failed on another. A development laptop with SSH access could produce a lockfile entry that later broke on a CI runner without the same key setup.
pnpm 12 removes that class of accidentally machine-local resolution.
If you need SSH for private repositories hosted on those services, the release notes point to configuring git at the machine level with URL rewriting. That way the project lockfile stays canonical, while the machine decides how it's allowed to reach the repository.
It's a good tradeoff for shared projects. The lockfile says what dependency is needed. The machine decides how it can obtain it.
## What happens with unrecognized settings in pnpm-workspace.yaml?
pnpm 12 can fail when `pnpm-workspace.yaml` contains a setting that pnpm doesn't recognize.
This is one of the discrete but important changes. In the previous behavior, a typo in a workspace setting could be silently ignored. The release notes use `minimumReleaseAge` as an example of the kind of policy where a typo would be dangerous: the team believes a supply chain control is active, but pnpm isn't enforcing it.
pnpm 12 reports unrecognized workspace settings and, when the project pins a pnpm version that the running version satisfies, fails with `ERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGS`.
That's a bit less permissive, but considerably safer.
Before updating a workspace, check `pnpm-workspace.yaml` for old settings, typos, or configuration that belonged to a different pnpm version. This is especially important in monorepos where package manager configuration tends to accumulate without much fanfare.
## How do shims for Node, Deno, Bun, and Yarn change?
pnpm 12 lets globally installed bins follow the project you're in.
The new `globalShims` setting controls which globally installed packages receive project-aware shims. The default value includes `node`, `deno`, and `bun`.
In practice, that means a project that pins Node.js via runtime fields supported by pnpm can download the pinned stable version of Node on first use and run it when you type `node` inside the project. The release notes say that stable versions of Node are authenticated against signatures from the Node.js release team. Other candidates, like Deno, Bun, Node.js prereleases, or ordinary bins you explicitly enable, can request trust from the project.
This matters because JavaScript projects increasingly pin not just dependencies, but toolchains. pnpm 12 moves more of that toolchain selection toward project-aware behavior, rather than relying on shell hooks, local conventions, or whichever binary happens to appear first in `PATH`.
There are also emergency exits: `globalShims: false` disables the feature, and `PNPM_SHIM_BYPASS=1` bypasses it on one invocation.
For teams, the important thing is policy. Decide whether local development, CI, and build agents should honor these shims, and make that decision explicit.
## What changes with package-manager pins?
pnpm 12 can provision other package managers, not just pnpm.
The release notes say pnpm now handles npm, Yarn Classic, Yarn Berry, Yarn 6, and Bun via trusted registries of package managers, with signature verification where applicable for managers published to npm.
This shows up in three places.
First, a dependency hosted on git can be set up with the package manager it requests. If a dependency pins Yarn, pnpm can provision the required Yarn version instead of assuming the machine already has it.
Second, `pnpm dlx` can directly run a package manager. The release notes show examples like:
```sh
pnx yarn@4 install
pnx npm@11 ci
pnx bun@1.3.0 install
Third, pnpm shim add yarn can create a command that runs the version pinned by the current project.
This is a behavior change from treating names like yarn or node as ordinary npm packages. In pnpm 12, those names can refer to the actual package manager or runtime.
It’s useful, but it can surprise scripts that relied on the old meaning. Audit global installations, bootstrap scripts, and setup documentation before assuming that pnpm add -g yarn or pnx node mean the same thing as in pnpm 11.
What should you review before updating CI?
Before updating CI to pnpm 12, review the places where installation behavior crosses boundaries between machines.
Start with the package manager installation path. If your CI image uses npm latest, Homebrew, winget, Scoop, or Chocolatey, check whether those channels really deliver pnpm 12 at the time you make the change.
Next review git dependencies. If your lockfile currently records SSH URLs for GitHub, GitLab, or Bitbucket dependencies, expect a re-resolution path toward a canonical HTTPS identity. For private repositories, set up git URL rewriting at the machine level instead of hardcoding SSH transport within the project.
Then review pnpm-workspace.yaml. A typo in a setting that previously hid silently can now cause a command to fail, which is exactly what you want from a policy file, but it’s good to catch it before a production build.
Next, review scripts that mention package managers and runtimes by name. yarn, npm, bun, node, and deno can now participate in pnpm’s provisioning and shims behavior. That’s an advantage when you want to enforce project pins, and a source of confusion if your CI expects global binaries to ignore the project.
Finally, prepare yourself for a one-time lockfile normalization when a dependency change triggers a re-resolution. Frozen installs should continue working with existing lockfiles, but the next actual dependency update may produce a cleaner and more deterministic lockfile.
Why pnpm 12 Matters for Developers in Latin America
pnpm 12 matters because reproducible installs are no longer an abstract concern. They decide whether a team can trust CI, onboard developers quickly, and move between local machines, containers, and runners without losing hours to package manager drift.
The release isn’t just about speed, though pnpm reports faster peer resolution and lower memory usage in large workspaces with many cycles. The bigger story is control.
A lockfile shouldn’t depend on luck in the graph traversal. A git dependency shouldn’t depend on the SSH configuration of the laptop that resolved it first. A workspace security setting shouldn’t disappear because of a typo. A project pin should mean the same thing on a development machine and inside CI.
That’s the practical value of pnpm 12.
If your project is small, the upgrade might be almost boring. If your workspace is large, old, or shared across multiple environments, pnpm 12 deserves an intentional trial run: run it on a branch, re-resolve once, inspect the lockfile diff, review workspace settings, and update CI only after understanding which changes are deterministic cleanup and which affect your own scripts.
The package manager is infrastructure. pnpm 12 makes that infrastructure more explicit.