// HACKER NEWS — CYBERSECURITY
Pnpm 12.0
pnpm 12 is stable. It is a rewrite of pnpm in Rust, and it is deliberately not a migration: the commands, flags, settings, and lockfile format of pnpm 11 all carry over, and the documentation describes both versions.
The short list of things that genuinely behave differently is in What's different in pnpm 12. This post covers what pnpm 12 adds that pnpm 11 never shipped.
latest on npm still points at the pnpm 11 line, so pnpm 12 is installed from the next-12 tag:
See Installing pnpm 12 for the other ways, including without Node.js. Homebrew, winget, Scoop, and Chocolatey don't offer it yet.
For repositories on GitHub, GitLab, and Bitbucket, a specifier now names a repository rather than choosing a transport. github:owner/repo, owner/repo, git+https://…, and git+ssh://git@… all resolve through the host's canonical HTTPS URL, and the lockfile never records an SSH URL for those hosts. To reach a private hosted repository over SSH, configure the machine with git's own URL rewriting:
pnpm shells out to git, so the rewrite applies to all of its git operations. Unknown hosts keep their exact URL, SSH included, and a URL with embedded credentials is kept verbatim and never resolves to a host archive. Details in How git dependencies are resolved.
A setting pnpm does not recognize used to be ignored in silence — a misspelled minimumReleaseAge dropped the policy it was meant to set, and nothing said so. It is now reported, with the closest real setting name suggested when the key looks like a typo.
It fails the command with ERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGS when the project pins a pnpm version the running pnpm satisfies: with the pin honored, the setting cannot have been meant for a different pnpm version, so it is a mistake to fix rather than a key to ignore. Everywhere else it is a warning, so a project that has yet to be cleaned up keeps working. The pnpm config subcommands never fail on it, so a broken file can still be inspected and repaired.
Dependency cycles are now broken canonically during peer resolution: the members of each cycle are ordered by package id, and the edges that close a cycle are always cut at the same place, wherever the installation walks into the cycle from.
The lockfile therefore becomes a pure function of the dependency graph — reordered importers, reordered dependencies, and repeated installs all produce byte-identical lockfiles, which they could not before (#13846, #13865). On large cycle-heavy workspaces peer resolution is 2–3× faster, uses about 25% less memory, and produces a substantially smaller lockfile.