Passa al contenuto principale

pnpm 11.24

· 4 minuti di lettura
Zoltan Kochan
Zoltan Kochan
Lead maintainer of pnpm

pnpm 11.24 brings back pnpm approve-builds --global, which isolated global installs took away in v11.0, and makes recursive batch publishing group its packages by registry so a credential mismatch is caught before anything is published. It also stops --frozen-lockfile from failing over the pnpm version the lockfile pins.

Minor Changes​

Global build approvals​

pnpm approve-builds --global works again (#14101).

It was removed in v11.0.0, when global installs became isolated: every install group got its own manifest, and there was no single place for the command to write an answer to. It now aggregates the packages awaiting approval across all install groups, asks about them once, and writes one allowBuilds policy into the pnpm-workspace.yaml of the global packages directory. Only the groups that actually contain an approved package are rebuilt.

pnpm approve-builds -g

The alternatives are unchanged: pnpm add -g --allow-build=esbuild esbuild still pre-approves at install time, and a global install still prompts.

Patch Changes​

Batch publishing groups by registry​

When pnpm -r publish --batch sends a workspace to the registry, the selected packages are now grouped by the registry each one publishes to, and one batch request is sent per group.

A group has to authenticate with one credential — a scope-specific token shared across the group is fine — and mismatched credentials for a registry are rejected before publishing rather than after part of the release has already gone out. The publish and postpublish scripts run after each completed group.

A pinned pnpm version no longer fails a frozen install​

Two ways pnpm install --frozen-lockfile could fail over the pnpm version recorded in pnpm-lock.yaml are fixed (#14124):

  • When the pin has to be re-resolved before it can be installed, pnpm now runs the version the lockfile pins and leaves the lockfile alone, instead of failing with ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE.
  • When the lockfile records the pinned version alongside an engine package this pnpm does not install it from, the install proceeds. An entry pinning a different version is still refused, and a plain install rewrites the block.

Merged branch lockfiles drop removed dependencies​

pnpm install --merge-git-branch-lockfiles --frozen-lockfile no longer fails with ERR_PNPM_OUTDATED_LOCKFILE when a branch lockfile predates the removal of a dependency, or its move to another dependency group (#13966). A dependency no project declares any more is not reinstated by the merge, and the packages it was the only path to are dropped with it.

Injected directory dependencies keep their peer variants​

Under nodeLinker: hoisted, peer-resolution variants of an injected directory dependency (a file: snapshot) are materialized as separate copies again, instead of collapsing onto the first-seen variant. Each copy keeps its own peer-resolved dependency set, so a project pinning one peer version no longer resolves another project's variant.

Settings the Rust CLI recognized but ignored​

This release ships alongside pnpm v12.0.0-rc.10, in which the Rust CLI starts honoring five settings it had been parsing and discarding: updateNotifier, legacyDirFiltering, initAuthorName / initAuthorEmail / initAuthorUrl, initLicense, and initVersion. PNPM_CONFIG_INIT_VERSION is read as well. All five have worked in pnpm 11 all along — the pnpm init settings and legacyDirFiltering simply had no documentation until now.

maxsockets is no longer ignored under npm's spelling either: maxsockets and maxSockets are both read from pnpm-workspace.yaml, the global configuration file, the environment, and the command line, in that increasing order of precedence — so a value passed on the command line wins even when the two sides spelled the setting differently.

Two smaller corrections come with it. A lastUpdateCheck timestamp dated in the future — after a clock change, a restored snapshot, or a hand-edited state file — no longer silences the update check until that time comes around. And confirmModulesPurge, a pnpm 11 setting, is reported as such instead of being called unrecognized and matched against an unrelated setting name.

legacyDirFiltering and the selectors pnpm writes itself​

legacyDirFiltering no longer reaches the workspace-root selectors pnpm generates for its own commands: the !{<workspace-root>} exclusion a recursive run / exec / add / test appends, and the {<workspace-root>} inclusion --workspace-root appends.

Read as subtree matches, those named every project below the root — so a recursive command under the setting selected nothing at all, and --workspace-root pulled in the whole workspace instead of the root alone (#14101).