pnpm 11.4 closes a cluster of supply-chain holes around lockfile integrity, credential scoping, git resolutions, patch files, and dependency aliases, makes tarball-integrity mismatches a hard install failure by default (with a narrowly-scoped --update-checksums opt-in), and changes pnpm runtime set to write to devEngines.runtime instead of engines.runtime by default.

Незначні зміни​

Tarball-integrity mismatches are now a hard failure​

Previously, pnpm install (non-frozen) would log ERR_PNPM_TARBALL_INTEGRITY when a downloaded tarball's hash didn't match the lockfile, silently re-resolve from the registry, and overwrite the locked integrity. A compromised registry, proxy, or republished version could therefore substitute attacker-controlled content on a clean machine even though the project shipped a committed lockfile.

pnpm install now exits with ERR_PNPM_TARBALL_INTEGRITY and a hint pointing at the new opt-in flag.

The only opt-in is pnpm install --update-checksums — narrowly scoped to refreshing the locked integrity values from what the registry currently serves. It mirrors yarn's flag of the same name. A warning still prints when the bypass takes effect so the operation is auditable.

--force and pnpm update deliberately do not bypass the integrity check. They are routine refresh operations; silently overwriting a locked integrity in those flows would erase the protection a committed lockfile is supposed to provide. --frozen-lockfile behavior is unchanged. --fix-lockfile keeps its documented purpose (filling in missing lockfile entries) and is also not a bypass.

pnpm runtime set writes to devEngines.runtime by default​

pnpm runtime set <name> <version> now saves the runtime to devEngines.runtime by default instead of engines.runtime. Pass --save-prod (or -P) to save it to engines.runtime instead. See #11948.

Зміни в патчах​

Security: unscoped credentials no longer leak across registries​

An unscoped _authToken (or _auth, or username + _password, or tokenHelper) defined in one source — ~/.npmrc, ~/.config/pnpm/auth.ini, a workspace .npmrc, CLI flags, etc. — would be sent as an Authorization header to whichever registry a different (potentially untrusted) source named. The same exposure extended to client TLS credentials (cert, key).

pnpm now rewrites each unscoped per-registry setting (_authToken, _auth, username, _password, tokenHelper, cert, key) to its URL-scoped form at load time, using the registry= value declared in the same source (or the npmjs default registry if the source declares none). A later layer overriding registry= therefore cannot pull an unscoped credential along, because it is already pinned to the URL its author intended. ca / cafile are intentionally not rescoped — they're trust anchors, not credentials, and corporate MITM-proxy setups rely on them applying globally.

Every rescope emits a deprecation warning telling the user where the setting was pinned and how to write it directly. npm has rejected unscoped credentials outright since npm@9, and pnpm intends to remove support in a future major release. To target a specific registry, write the setting URL-scoped:

//registry.example.com/:_authToken=...
//registry.example.com/:cert=...

Security: lockfile entries without integrity are rejected​

Previously, the worker that extracts a downloaded tarball skipped hash verification when no integrity was supplied and minted a fresh one from the unverified bytes. An attacker who could both alter the lockfile (e.g. via a pull request that strips integrity:) and serve modified content at the referenced tarball URL could install a tampered package without any error — including under --frozen-lockfile.

pnpm now fails closed at lockfile-read time with ERR_PNPM_MISSING_TARBALL_INTEGRITY. Git-hosted tarballs (gitHosted: true or a URL on codeload.github.com / bitbucket.org / gitlab.com) and file: tarballs are exempt — the commit SHA in a git-host URL and the user-controlled local path already anchor the bytes.

Security: git resolutions reject non-SHA commit fields​

Git resolutions whose commit field is not a 40-character hexadecimal SHA are rejected before git is invoked. A malicious lockfile could otherwise smuggle a value such as --upload-pack=<command> through git fetch / git checkout, which on SSH or local-file transports executes the supplied command.

Security: patch files writing outside the package directory are rejected​

Patch files whose diff --git headers reference paths outside the patched package directory are now rejected. Previously a malicious .patch file added via a pull request could write, delete, or rename arbitrary files reachable by the user running pnpm install.

Security: dependency aliases with path-traversal segments are rejected​

Dependency aliases that contain path-traversal segments (such as @x/../../../../../.git/hooks) are rejected when read from a package manifest or symlinked into node_modules. A malicious registry package could otherwise use a transitive dependency key to make pnpm install create symlinks at attacker-chosen paths outside the intended node_modules directory.

Trusted-publisher metadata now requires provenance​

Trusted publisher metadata is only treated as the strongest trust evidence when provenance is also present.

Other fixes​

• Fix pnpm deploy crashing with ENOENT: ... lstat '<deployDir>/node_modules' when configDependencies declares pacquet (pacquet or @pnpm/pacquet). The deploy directory never installs config dependencies, so the install engine they designate isn't on disk to invoke; the nested install now skips them.
• Limit concurrent project manifest reads while listing large workspaces to avoid EMFILE errors.
• Validate devEngines.runtime and engines.runtime version ranges for node, deno, and bun when onFail is set to error or warn. Previously these settings only had an effect with onFail: 'download' — the error and warn modes silently did nothing #11818. Violations now throw ERR_PNPM_BAD_RUNTIME_VERSION.
• Improve the log message that pnpm prints after auto-adding entries to minimumReleaseAgeExclude when minimumReleaseAge is set without minimumReleaseAgeStrict. The message previously referred to the internal "loose mode" terminology, which wasn't searchable in the docs; it now tells the user to set minimumReleaseAgeStrict to true if they want these updates gated behind a prompt instead #11747.

pnpm 11.3 adds support for npm's staged publishing (pnpm stage), the new trustLockfile setting for skipping the supply-chain verification pass on already-trusted lockfiles, and native implementations of pnpm pkg, pnpm repo, and pnpm set-script. It also adds a --skip-manifest-obfuscation flag for pack / publish and cuts the memory footprint of minimumReleaseAge / trustPolicy verification on large workspaces.

Незначні зміни​

pnpm stage​

A new pnpm stage command brings npm's staged publishing workflow to pnpm. Staged publishing lets you publish a version that's hidden from npm install until you explicitly approve it — useful for verifying release artifacts, smoke-testing CI, or coordinating multi-package releases.

The available subcommands are:

pnpm stage publish    # publish a version into staging
pnpm stage list       # list staged versions
pnpm stage view       # view a staged version
pnpm stage approve    # promote a staged version to the registry
pnpm stage reject     # discard a staged version
pnpm stage download   # download a staged tarball

trustLockfile​

A new trustLockfile setting controls whether pnpm install re-applies the minimumReleaseAge / trustPolicy: 'no-downgrade' checks to every entry in the loaded lockfile. When true, the install treats the lockfile as already-trusted and skips the verification pass — useful for closed-source projects where every commit comes from a trusted author. The default is false, so verification stays on by default.

Set it in pnpm-workspace.yaml:

trustLockfile: true

This release also cuts the memory footprint of the verification pass itself: the per-(registry, name) trust-meta cache previously retained the full packument — dependency graphs, scripts, README, and per-version manifests — for the entire install. On large workspaces (~4k lockfile entries with minimumReleaseAge + trustPolicy: no-downgrade enabled) this could OOM CI runners with a 2 GB heap cap. The cache now stores only the fields the trust check actually reads (time, per-version _npmUser.trustedPublisher, dist.attestations.provenance); the abbreviated-metadata cache is similarly projected to just the package-level modified field and the set of currently-listed version names. Fixes #11860.

Native pnpm pkg, pnpm repo, and pnpm set-script​

Three more commands that previously delegated to (or were missing without) npm are now implemented natively, following the npm command conventions:

• pnpm pkg — get / set / delete fields in package.json.
• pnpm repo — open the repository URL of a package in the browser.
• pnpm set-script (alias ss) — add or update an entry in the scripts field of the project manifest. Supports package.json, package.json5, and package.yaml formats.

--skip-manifest-obfuscation for pack and publish​

A new --skip-manifest-obfuscation flag for pnpm pack and pnpm publish keeps the original packageManager field and publish lifecycle scripts in the packed/published manifest instead of stripping them. The pnpm-specific pnpm field continues to be omitted.

Зміни в патчах​

• Fixed pnpm dlx failing with ERR_PNPM_NO_IMPORTER_MANIFEST_FOUND when the installed package's CAS slot is missing its package.json. Observed in the wild for pnpm dlx node@runtime:<version> when the GVS slot was populated without the synthesized manifest runtime archives need. dlx now falls back to the scopeless package name when the slot's manifest is unreadable — for single-bin packages (the dlx common case, including every runtime: spec) this matches what manifest.bin would have named.
• Fixed non-determinism in pnpm dedupe and pnpm install when a dependency graph contains packages with transitive peer dependencies on each other (e.g. @aws-sdk/client-sts and @aws-sdk/client-sso-oidc) and auto-install-peers is enabled. The lockfile no longer flips between two equally-valid forms across consecutive runs. The root cause was that resolveDependencies pushed onto its pkgAddresses / postponedResolutionsQueue arrays from inside Promise.all-spawned callbacks, so completion-order timing leaked into the array order and downstream cyclic-peer suffix assignment. Fixes #8155.
• Fixed a regression where pnpm add <github-shorthand> (and any other wanted-dependency whose alias can't be parsed from the user-supplied spec, e.g. tarball URLs or pnpm/test-git-fetch#sha) was silently dropped from the manifest update and from pendingBuilds.
• Fixed pnpm add --config leaving orphan entries in pnpm-lock.env.yaml (the optional subdependencies of the previously resolved version of the updated config dependency).

pnpm 11.2 ships an experimental opt-in into pacquet (the Rust port of pnpm) as the install backend, expands config dependencies to install one level of optionalDependencies (so the esbuild/swc platform-binary pattern works for config deps too), wires up the long-documented pnpm login --scope flag, and surfaces runtime entries (Node.js, Deno, Bun) in pnpm outdated and pnpm update --interactive.

Незначні зміни​

Experimental: pacquet as the install backend​

Adding @pnpm/pacquet (the Rust port of pnpm) to configDependencies in pnpm-workspace.yaml now delegates the materialization phase of pnpm install to the pacquet binary. pnpm still owns dependency resolution; pacquet only fetches and imports from the freshly-written lockfile. This is an opt-in preview of the Rust install engine — see #11723.

To configure pacquet in a project, run:

pnpm add @pnpm/pacquet --config

You'll see changes in pnpm-workspace.yaml and pnpm-lock.yaml that should be committed. If you experience any issues with pacquet, please let us know in the GitHub issue you create.

optionalDependencies for config dependencies​

Config dependencies now resolve and install one level of optionalDependencies declared by the config dependency, with os / cpu / libc platform filtering applied at install time. This unlocks the esbuild/swc-style pattern where a package ships platform-specific binaries via optionalDependencies — a config dependency can now do the same and have the matching binary symlinked next to it in the global virtual store, so require('pkg-platform-arch') from inside the config dependency resolves correctly.

The env lockfile records all platform variants regardless of host platform, so it remains portable across machines. Each entry in a config dependency's optionalDependencies must declare an exact version — ranges and tags are rejected to keep installs reproducible.

pnpm login --scope​

The long-documented pnpm login --scope <scope> flag is now implemented. The scope is normalized (a leading @ is added if missing; blank values are ignored) and an @<scope>:registry=<registry> mapping is written to the pnpm auth file alongside the auth token. Subsequent installs of @<scope>/* packages then route to the chosen registry. Previously the documented flag errored with Unknown option: 'scope'. See #11716.

Runtimes in outdated and update --interactive​

pnpm outdated and pnpm update --interactive now report Node.js, Deno, and Bun runtimes installed as project dependencies (runtime: specifiers). Previously these were silently skipped.

Зміни в патчах​

• Fixed cafile=<relative-path> in .npmrc being read from the wrong directory when pnpm is invoked from a different cwd (e.g. pnpm --dir <project> install from a CI wrapper or monorepo script). The path is now resolved against the directory of the .npmrc that declared it, not process.cwd(). Before this fix, the install proceeded without the configured CA and the user only saw TLS errors against a private registry with no log line tying back to the wrongly resolved path #11624.
• Fixed config.registry getting a trailing slash appended when registry is set in .npmrc and no registries.default is provided by pnpm-workspace.yaml.
• Fixed global add/update to handle minimumReleaseAge policy violations instead of surfacing an internal resolver guardrail error.
• Fixed two crashes with injectWorkspacePackages: true when the lockfile has been pruned (e.g. by turbo prune --docker): a Cannot use 'in' operator to search for 'directory' in undefined from peer-dependency-variant injected snapshots whose base packages: entry had been dropped, and an ERR_PNPM_ENOENT on node_modules/.bin/<tool> after prepare / postinstall re-imported each injected workspace package.
• Fixed pnpm login and pnpm logout ignoring registries.default from pnpm-workspace.yaml #10099.
• Fixed the minimumReleaseAge (publishedBy) maturity shortcut to be inclusive at the cutoff. Previously, abbreviated metadata whose modified field equalled the cutoff fell off the fast path and triggered a full-metadata re-fetch (or a MISSING_TIME error when full metadata wasn't permitted).
• Honor publishConfig.access when publishing packages.

11.2.1​

• Mark optional subdependency snapshots of config dependencies with optional: true in the env lockfile, matching how optional dependencies are recorded elsewhere in pnpm-lock.yaml. Previously, snapshots for the platform-specific subdeps pulled in via a config dep's optionalDependencies were written as empty objects.
• Fixed pickRegistryForPackage returning the wrong registry for an unscoped npm: alias under a scoped local name. A manifest entry like "@private/foo": "npm:lodash@^1" was routing the lodash fetch through registries["@private"], even though lodash is unscoped.
• Don't print Installing config dependencies... when config dependencies are already installed and nothing needs to be fetched, re-linked, or removed.

11.2.2​

• When the install engine is delegated to pacquet via configDependencies, the user's CLI flags passed to pnpm install (e.g. --no-runtime, --prod, --dev, --no-optional, --node-linker, --cpu / --os / --libc, --offline, --prefer-offline) are now forwarded to pacquet's install subcommand verbatim. Previously pacquet was invoked with a fixed argument list, so flags like --no-runtime were silently dropped. Flag forwarding is gated on the command being install / i; add, update, and dedupe still don't forward (their flag surface doesn't line up with pacquet's install).
• Fixed pnpm up (and pnpm add / pnpm remove) failing with pacquet_package_manager::outdated_lockfile when pacquet is declared in configDependencies. pnpm now passes --ignore-manifest-check to pacquet so its --frozen-lockfile check doesn't fire against the (pre-mutation) package.json pnpm hasn't written yet #11797.

pnpm 11.1 adds a few new commands — pnpm audit signatures, pnpm bugs, and pnpm owner — alongside support for installing from arbitrary named registries (including a built-in alias for the GitHub Packages npm registry), the ability to skip runtime installation in CI, and several fixes.

Незначні зміни​

pnpm audit signatures​

A new pnpm audit signatures subcommand verifies ECDSA registry signatures for installed packages against keys published at /-/npm/v1/keys #7909. Scoped registries are respected; registries that don't publish signing keys are skipped.

pnpm audit signatures

Named registries (and a built-in gh: alias)​

You can now install packages from the GitHub Packages npm registry via a built-in gh: prefix, and — more broadly — from arbitrary named registries in the style of vlt's named-registry aliases:

pnpm add gh:@acme/private

Authentication is picked up from existing per-URL .npmrc entries (e.g. //npm.pkg.github.com/:_authToken=...), so no separate auth mechanism is required.

Additional aliases — or an override for the built-in gh alias, for GitHub Enterprise Server — can be configured under namedRegistries in pnpm-workspace.yaml:

namedRegistries:
  gh: https://npm.pkg.github.example.com/
  work: https://npm.work.example.com/

With this, work:@corp/lib@^2.0.0 resolves against https://npm.work.example.com/. Див. #8941.

--sbom-spec-version​

pnpm sbom now accepts a --sbom-spec-version flag to choose the CycloneDX specification version (1.5, 1.6, or 1.7 — default 1.7). The flag is only valid with --sbom-format cyclonedx. Див. #11389.

--no-runtime for CI matrices​

A new --no-runtime flag (config: runtime=false) skips installing runtime entries (e.g. Node.js downloaded via devEngines.runtime) without modifying the lockfile. The lockfile keeps the runtime entry so frozen-lockfile validation still passes; only the runtime fetch and .bin linking are skipped. This is useful in CI matrices where the runtime is provisioned externally (e.g. via pnpm runtime -g set node <version>) before pnpm install runs.

pnpm bugs​

The new pnpm bugs command opens a package's bug tracker URL in the browser. With no arguments, it reads the current project's package.json; with one or more package names, it fetches each package's metadata from the registry and opens its bug tracker. It falls back to <repository>/issues when the bugs field is missing. Див. #11279.

pnpm owner​

The new pnpm owner command manages package owners on the registry:

pnpm owner ls <package>
pnpm owner add <package> <user>
pnpm owner rm <package> <user>

Зміни в патчах​

• pnpm view now prints "published X ago by Y" alongside the rest of its output, mirroring npm view. This is useful when comparing against minimumReleaseAge. For example, pnpm view pnpm now shows published 17 hours ago by GitHub Actions.

• pnpm publish now honors the configured HTTP/HTTPS proxy (including the https_proxy / http_proxy / no_proxy environment variables) when polling the registry's doneUrl during the web-based authentication flow. Previously the poll bypassed the proxy, causing the registry to respond 403 from a different source IP and the login to never complete #11561.

• pnpm add -g now installs each space-separated package into its own isolated directory by default. To bundle multiple packages into the same isolated install (so they share dependencies and are removed together), pass them as a comma-separated list. Наприклад:

  • pnpm add -g foo bar installs foo and bar as two independent globals — removing one does not affect the other.
  • pnpm add -g foo,bar qar bundles foo and bar into a single isolated install while qar is installed on its own.

  Related: #11587.

• pnpm runtime set <name> <version> no longer fails in the root of a multi-package workspace with the ADDING_TO_ROOT error. Installing the workspace root is a valid target for a runtime, so the command now bypasses that safety check.

• Fixed pnpm --version hanging for the lifetime of the worker pool after the version was printed. The CLI entry now runs finishWorkers() from its own finally, so every exit path tears the pool down.

pnpm 11 is here! This release tightens the security defaults introduced throughout the v10 cycle, drops the npm CLI fallback for publishing in favor of a native implementation, replaces the JSON-per-package store index with a single SQLite database, and isolates global installs so they no longer interfere with each other.

It also requires Node.js 22 or newer — pnpm itself is now pure ESM.

Upgrading from v10? See the Migrating from v10 to v11 guide. Most config changes are mechanical and can be applied by the pnpm-v10-to-v11 codemod.

Highlights​

• Node.js 22+ required. Support for Node 18, 19, 20, and 21 is dropped. The standalone executable requires glibc 2.27 or newer.
• Supply-chain protection on by default. minimumReleaseAge defaults to 1440 (1 day) and blockExoticSubdeps defaults to true.
• allowBuilds replaces the legacy build-dependency settings. onlyBuiltDependencies, onlyBuiltDependenciesFile, neverBuiltDependencies, ignoredBuiltDependencies, and ignoreDepScripts are gone.
• Global installs are isolated and use the global virtual store by default. Each pnpm add -g gets its own directory with its own package.json, node_modules, and lockfile.
• New SQLite-backed store index (store v11), with bundled manifests and hex digests for fewer syscalls and faster installs.
• Native publish flow. pnpm publish, login, logout, view, deprecate, unpublish, dist-tag, and version no longer delegate to the npm CLI.
• .npmrc is auth/registry only. Other settings must live in pnpm-workspace.yaml or the new global config.yaml. Environment variables use the pnpm_config_* prefix.

Breaking changes​

Requirements​

• Drops Node.js 18, 19, 20, and 21.
• pnpm is now distributed as pure ESM.
• The standalone exe requires glibc 2.27+.

Security & build defaults​

Several defaults have flipped to safer values:

Newly published packages won't be resolved until they're at least 1 day old. Щоб відмовитися від цього, встановіть значення minimumReleaseAge: 0 у файлі pnpm-workspace.yaml.

allowBuilds replaces the old build settings​

onlyBuiltDependencies, onlyBuiltDependenciesFile, neverBuiltDependencies, ignoredBuiltDependencies, and ignoreDepScripts have all been removed. Use allowBuilds instead — a map from package name patterns to booleans:

Before:

onlyBuiltDependencies:
  - electron
onlyBuiltDependenciesFile: "allowed-builds.json"
neverBuiltDependencies:
  - core-js
ignoredBuiltDependencies:
  - esbuild

After:

allowBuilds:
  electron: true
  core-js: false
  esbuild: false

Also removed: allowNonAppliedPatches (use allowUnusedPatches) and ignorePatchFailures (patch failures now throw).

.npmrc is auth/registry only​

pnpm no longer reads non-auth settings from .npmrc. Configuration is split into two categories:

• Registry and auth settings — INI files (.npmrc, the global rc file, ~/.config/pnpm/auth.ini).
• pnpm-specific settings — YAML files (pnpm-workspace.yaml, the new global ~/.config/pnpm/config.yaml).

Other related changes:

• pnpm no longer reads npm_config_* environment variables. Use pnpm_config_* instead (e.g. pnpm_config_registry).

• pnpm no longer reads the pnpm field in package.json.

• pnpm no longer reads npm's global config at $PREFIX/etc/npmrc.

• Network settings (httpProxy, httpsProxy, noProxy, localAddress, strictSsl, gitShallowHosts) are now written to config.yaml / pnpm-workspace.yaml (still readable from .npmrc to ease migration).

• A new registries setting in pnpm-workspace.yaml replaces @scope:registry= lines:

  registries:
    default: https://registry.npmjs.org/
    "@my-org": https://private.example.com/
    "@internal": https://nexus.corp.com/
  

• Per-project .npmrc is replaced by packageConfigs in pnpm-workspace.yaml:

  packages:
    - "packages/project-1"
    - "packages/project-2"
  packageConfigs:
    "project-1":
      saveExact: true
    "project-2":
      savePrefix: "~"
  

Native publish flow, no more npm CLI fallback​

Commands previously implemented by passing through to the npm CLI have either been reimplemented natively or removed.

Reimplemented: publish, view (info, show, v), login (adduser), logout, deprecate, unpublish, dist-tag, version, search, star/unstar/stars, whoami, ping, docs/home.

Removed (now throw "not implemented"): access, bugs, edit, issues, owner, prefix, profile, pkg, repo, set-script, team, token, xmas.

A few notes on the new native pnpm publish:

• The OTP environment variable is now PNPM_CONFIG_OTP (was NPM_CONFIG_OTP).
• If the registry asks for OTP and none is provided, pnpm prompts for it interactively.
• Web-based authentication shows a scannable QR code and URL.

pnpm audit uses the bulk advisories endpoint​

The legacy /-/npm/v1/security/audits{,/quick} endpoints have been retired by the registry. pnpm audit now calls /-/npm/v1/security/advisories/bulk, which doesn't return CVE identifiers — so CVE-based filtering has been replaced with GHSA-based filtering:

• auditConfig.ignoreCves → auditConfig.ignoreGhsas
• pnpm audit --ignore <id> and --ignore-unfixable read and write GHSAs

To migrate, replace each CVE-YYYY-NNNNN entry under ignoreCves with the matching GHSA-xxxx-xxxx-xxxx (visible in the More info column of pnpm audit) and move it to ignoreGhsas.

Isolated, global-virtual-store global installs​

pnpm add -g <pkg> and pnx now use the global virtual store, and each install gets its own isolated directory at {pnpmHomeDir}/global/v11/{hash}/ with its own package.json, node_modules/, and lockfile. This stops global packages from interfering with each other through peer-dependency conflicts, hoisting changes, or version drift.

• pnpm remove -g <pkg> removes the entire installation group containing the package.
• pnpm update -g [pkg] re-installs into a new isolated directory.
• pnpm list -g scans isolated directories.
• pnpm install -g (no args) is no longer supported — use pnpm add -g <pkg>.

Globally installed binaries now live in a bin subdirectory of PNPM_HOME (rather than directly in PNPM_HOME), so internal directories like global/ and store/ don't pollute shell autocompletion. Run pnpm setup after upgrading to update your shell configuration.

pnpm link has been tightened too: only relative or absolute paths are accepted, --global is removed (use pnpm add -g .), and pnpm link with no arguments is removed.

Other removals​

• pnpm server.

• useNodeVersion and executionEnv.nodeVersion — use devEngines.runtime / engines.runtime.

• hooks.fetchers — replaced by the new fetchers field in pnpmfile.

• managePackageManagerVersions, packageManagerStrict, and packageManagerStrictVersion. These all derived the onFail behavior of the legacy packageManager field; the new pmOnFail setting subsumes them:

  Removed	Replace with
  managePackageManagerVersions: true	pmOnFail: download (default)
  managePackageManagerVersions: false	pmOnFail: ignore
  packageManagerStrict: false	pmOnFail: warn
  packageManagerStrictVersion: true	pmOnFail: error
  COREPACK_ENABLE_STRICT=0	pmOnFail: warn

New commands​

Plus the natively reimplemented commands listed under "Native publish flow" above, and short aliases pn for pnpm and pnx for pnpx/pnpm dlx.

pnpm audit --fix=update​

Fix vulnerabilities by updating packages in the lockfile instead of adding overrides. For more granular control, the new --interactive / -i flag lets you select which advisories to fix:

pnpm audit --fix=update --interactive

pnpm audit --fix also adds the minimum patched version for each advisory to minimumReleaseAgeExclude in pnpm-workspace.yaml, so security fixes can be installed without waiting for minimumReleaseAge.

ESM pnpmfiles​

Pnpmfiles can now be written in ESM, using the .mjs extension. When .pnpmfile.mjs exists, it takes priority over .pnpmfile.cjs, and only one is loaded.

Store v11​

The store has been rebuilt around two ideas: read less, do fewer syscalls.

• The package index is now a single SQLite database at $STORE/index.db (with MessagePack values, WAL mode for concurrent access), instead of millions of JSON files under $STORE/index/. Packages missing from the new index are re-fetched on demand.
• The bundled manifest (name, version, bin, engines, scripts, etc.) is stored directly in the package index, eliminating the need to read package.json from the CAS during resolution and installation.
• Index entries store hex digests instead of full integrity strings (<algo>-<digest>), and the hash algorithm is recorded once per file instead of per entry. This avoids base64 → hex conversion on every CAS path lookup.
• When the global virtual store is enabled, packages that aren't allowed to build (and don't transitively depend on packages that are) get hashes that don't include the engine name (platform, arch, Node.js major). ~95% of GVS packages now survive Node.js upgrades and architecture changes without re-import.

Performance​

A lot of small wins add up to a noticeably faster install:

• undici replaces node-fetch for all HTTP, with Happy Eyeballs (dual-stack), better keep-alive, and an optimized global dispatcher.
• Tarball downloads with known size pre-allocate memory to avoid double-copy overhead.
• The metadata cache is now NDJSON, with If-Modified-Since for conditional fetches.
• minimumReleaseAge checks use the abbreviated metadata endpoint to fetch less.
• CAS files are written directly to their content-addressed path instead of via a temp file + rename — saving ~30k rename syscalls per cold install.
• The staging directory is gone when importing into node_modules.
• Hot-path string operations in the CAS were tightened, and gunzipSync runs with a larger chunk size for fewer buffer allocations during tarball decompression.
• During GVS warm reinstalls, redundant internal linking is skipped when no packages were added.

Slimmer runtime installs​

Installing a Node.js runtime via node@runtime:<version> (including pnpm env use and pnpm runtime set node) no longer extracts the bundled npm, npx, and corepack from the Node.js archive. That cuts roughly half of the files pnpm has to hash, write to the CAS, and link. If you still need npm, install it as a separate package.

Other notable changes​

• Cleaner script output. pnpm now prints $ command (to stderr, so stdout stays pipe-friendly) instead of > pkg@version stage path\n> command. Project name and path are shown only when running in a different directory.

• Peer dependency issues are no longer rendered as a tree during install — pnpm suggests running pnpm peers check to view them.

• Lifecycle scripts no longer get npm_config_* env vars from the pnpm config; only well-known npm_* env vars are set, matching Yarn.

• pnpm init writes devEngines.packageManager instead of packageManager when init-package-manager is enabled, and the default type is now "module".

• devEngines.packageManager now supports version ranges; the resolved version is stored in pnpm-lock.yaml and reused if it still satisfies the range.

• dedupePeers is a new setting that uses version-only suffixes (name@version) instead of full dep paths, eliminating nested suffixes like (foo@1.0.0(bar@2.0.0)) for projects with many recursive peers.

• pnpm approve-builds now accepts positional arguments for non-interactive use; prefix a name with ! to deny it.

• Hidden scripts — scripts starting with . can only be called from other scripts and don't show up in pnpm run.

• -F is a new short alias for --filter.

• pnpm add short flags — -d is now --save-dev, -p is --save-prod, -o is --save-optional, -e is --save-exact (only inside pnpm add).

• virtualStoreOnly populates the virtual store without creating importer symlinks, hoisting, bin links, or running lifecycle scripts. Useful for pre-populating a store in Nix builds. pnpm fetch now uses this internally.

• nodeDownloadMirrors in pnpm-workspace.yaml replaces the node-mirror:<channel> .npmrc setting:

  nodeDownloadMirrors:
    release: https://my-mirror.example.com/download/release/
  

• Config dependencies are now installed into {storeDir}/links/ and symlinked into node_modules/.pnpm-config/, so they're shared across projects using the same store. Resolved versions and integrity hashes have moved from pnpm-workspace.yaml to a separate document in pnpm-lock.yaml; old inline-hash projects are migrated automatically.

Upgrading​

See the full Migrating from v10 to v11 guide for the codemod and manual follow-ups. The short version:

• Bump your CI and dev environments to Node.js 22+ before upgrading.
• Move pnpm settings out of .npmrc into pnpm-workspace.yaml (or the global ~/.config/pnpm/config.yaml).
• Migrate onlyBuiltDependencies and friends to allowBuilds.
• Migrate auditConfig.ignoreCves to auditConfig.ignoreGhsas.
• After installing v11, run pnpm setup to update your shell so the new bin subdirectory is on PATH.

The full list of changes is in the changelog. If something you relied on is missing or broken, please open an issue at github.com/pnpm/pnpm/issues.

у версії pnpm 10.32 до команди pnpm approve-builds додано параметр --all, який дозволяє затверджувати всі очікувані збірки без інтерактивних запитів.

Незначні зміни​

Прапорець --all для команди pnpm approve-builds​

Додано прапорець --all до pnpm approve-builds, який схвалює всі збірки, що очікують на виконання, без інтерактивних запитів #10136.

pnpm approve-builds --all

Зміни в патчах​

• Скасовано зміну, повʼязану з явним встановленням шляху до конфігураційного файлу npm, що спричиняло регресії.
• Скасовано виправлення, повʼязане з lockfile-include-tarball-url. Виправляє #10915.

у версії pnpm 10.31 збережено коментарі та форматування під час оновлення файлу pnpm-workspace.yaml, а також виправлено чимало помилок.

Незначні зміни​

Збереження коментарів у pnpm-workspace.yaml​

Коли pnpm оновлює pnpm-workspace.yaml, коментарі, форматування рядків та пробіли залишаються.

Зміни в патчах​

• Додано -F як скорочення для опції --filter у виводі довідки.
• Обробка невизначеного pkgSnapshot у 'pnpm why -r' #10700.
• Виправлено ситуацію, коли headless інсталяція не використовувалася, якщо проєкт містив інʼєкцію залежності file:, що посилалась сама на себе, яка в файлі блокування перетворювалась на link:.
• Виправлено ситуацію конкуренції, яка виникала, коли кілька робочих потоків одночасно імпортували один і той самий пакунок у глобальне віртуальний сховище. Операція перейменування тепер допускає помилки ENOTEMPTY/EEXIST, якщо інший потік вже завершив імпорт.
• Якщо для параметра lockfile-include-tarball-url встановлено значення false, URL-адреси архівів тепер завжди виключаються з файлу блокування. Раніше URL-адреси архівів все ще могли зʼявлятися для пакунків, розміщених за нестандартними URL-адресами #6667.
• Виправлено пропускання установки функцією optimisticRepeatInstall у разі зміни параметрів overrides, packageExtensions, ignoredOptionalDependencies, patchedDependencies або peersSuffixMaxLength.
• Виправлено помилку pnpm patch-commit, яка виникала з повідомленням «unable to access “/.config/git/attributes”: Permission denied» у середовищах, де змінна HOME не встановлена або має нестандартне значення (контейнери Docker, системи CI) #6537.
• Виправлено помилку pnpm why -r --parseable, пов’язану з відсутністю залежностей, коли кілька пакунків робочого простору використовують одну й ту саму залежність #8100.
• Виправлено помилку, через яку параметр link-workspace-packages=true неправильно повʼязував пакети робочого простору, коли запитувана версія не відповідала версії пакунка робочого простору #10173.
• Виправлено помилку, через яку команда pnpm update --interactive порушувала вирівнювання таблиці при використанні довгих рядків версій, шляхом динамічного розрахунку ширини стовпців замість використання жорстко заданих значень #10316.
• Параметр, встановлений прапорцем --allow-build, записується в allowBuilds.
• Виправлено помилку, через яку при вказанні параметра filter у файлі pnpm-workspace.yaml pnpm не виявляв жодних проєктів.
• Вивести повідомлення про допомогу при запуску команди pnpm dlx без аргументів і завершити роботу.

у версії pnpm 10.30 команда pnpm why була перероблена для показу дерева зворотних залежностей, що значно полегшує розуміння причин встановлення того чи іншого пакунка.

Незначні зміни​

Дерево зворотних залежностей у pnpm why​

pnpm why тепер показує дерево зворотних залежностей. Пакунок, що шукається, зʼявляється в корені з його залежними елементами у вигляді гілок, які ведуть назад до коренів робочих просторів. Це замінює попередній вивід у вигляді дерева, який був захаращеним і важким для сприйняття у випадку глибоко вкладених залежностей.

Зміни в патчах​

• Оптимізовано продуктивність команд pnpm why та pnpm list у робочих просторах із великою кількістю імпортерів шляхом спільного використання графа залежностей та кешу матеріалізації для всіх імпортерів, замість їхньої окремої перекомпіляції для кожного з них #10596.

pnpm 10.29 додає підтримку протоколу catalog: до pnpm dlx, дозволяє налаштовувати auditLevel у pnpm-workspace.yaml, підтримує порожній специфікатор workspace: та містить кілька виправлень помилок.

Незначні зміни​

'catalog:' Протокол у 'pnpm dlx'​

Команда 'pnpm dlx' / 'pnpx' тепер підтримує протокол 'catalog:', що дозволяє звертатися до версій, визначених у каталогах робочого простору:

pnpm dlx shx@catalog:

Налаштування 'auditLevel'​

'auditLevel' тепер можна налаштувати у файлі 'pnpm-workspace.yaml', тож не потрібно передавати '--audit-level' при кожному виклику 'pnpm audit' #10540:

auditLevel: high

workspace: Протокол​

Тепер підтримується специфікатор workspace: без діапазону версій. Він розглядається як 'workspace:*' і перетворюється у конкретну версію під час публікації #10436:

{
  "dependencies": {
    "foo": "workspace:"
  }
}

Зміни в патчах​

• Виправлено помилку нестачі памʼяті в pnpm list (та pnpm why) на великих графах залежностей шляхом заміни рекурсивного конструктора дерев двофазним підходом: граф залежностей BFS з подальшою матеріалізацією кешованого дерева. Дублікати піддерев тепер видаляються у виводі #10586.
• Виправлено помилку allowBuilds не працює, якщо встановити через .pnpmfile.cjs #10516.
• Коли встановлено enableGlobalVirtualStore, pnpm deploy тепер ігнорує його та завжди створює локалізоване віртуальне сховище в теці розгортання, щоб забезпечити його автономність.
• Виправлено ситуацію, коли pnpm dlx не враховував параметр minimumReleaseAgeExclude #10338.
• Виправлено помилку, через яку команда pnpm list --json повертала неправильні шляхи при використанні глобального віртуального сховища #10187.
• Виправлено поведінку команд pnpm store path та pnpm store status: тепер для визначення шляху використовується коренева тека робочого простору, якщо параметр storeDir вказано у відносному форматі #10290.
• Виправлено ситуацію, коли під час повторного додавання наявної залежності каталогу до файлу pnpm-workspace.yaml записувався літеральний рядок catalog: замість визначеного специфікатора версії #10176.
• Пропускати локальні залежності протоколу file: під час виконання команди pnpm fetch, що дозволяє виправити збірку в Docker, коли локальні теки залежностей недоступні #10460.
• Виправлено роботу команди pnpm audit --json так, щоб вона враховувала параметр --audit-level як для коду завершення, так і для фільтрації виводу #10540.
• Оновлено tar до версії 7.5.7 для виправлення вразливості безпеки (CVE-2026-24842).
• Виправлено: команда pnpm audit --fix тепер замінює перевизначення посилань (наприклад, $foo) на конкретні версії #10325.
• Виправлено: параметр shamefullyHoist, заданий за допомогою updateConfig у файлі .pnpmfile.cjs, не перетворювався на publicHoistPattern #10271.
• Команда pnpm help тепер правильно повідомляє, чи входить поточна версія командного рядка pnpm до складу Node.js #10561.
• Додано попередження, якщо поточна тека містить символ-роздільник PATH, що може призвести до збою вставці шляху node_modules/.bin #10457.
• Виправлено URL-адресу документації, що показується в pnpm completion --help, щоб вона вказувала на правильну сторінку #10281.

У pnpm 10.28 представлено новий хук beforePacking для налаштування package.json під час публікації, покращено продуктивність інсталяції з використанням фільтрів та виправлено кілька помилок.

Незначні зміни​

Хук beforePacking​

Додано підтримку нового хука з назвою beforePacking, який дозволяє налаштовувати вміст package.json під час публікації, див. #3816.

Цей хук викликається безпосередньо перед створенням tar-архіву під час виконання команд pnpm pack або pnpm publish. Це дає вам можливість змінити маніфест пакунка, який буде включено до опублікованого пакунка, не впливаючи на ваш локальний файл package.json.

Приклад використання у .pnpmfile.cjs:

module.exports = {
  hooks: {
    beforePacking(pkg) {
      // Видалити поля, призначені тільки для розробки
      delete pkg.devDependencies
      delete pkg.scripts
      // Додати метадані публікації
      pkg.publishedAt = new Date().toISOString()
      return pkg
    }
  }
}

Див. документацію .pnpmfile.cjs для отримання додаткової інформації.

Продуктивність інсталяції з використанням фільтрів​

У деяких випадках інсталяція з використанням фільтрів (наприклад, pnpm install --filter ...) була повільнішою, ніж запуск pnpm install без будь-яких фільтрів. Цей регрес продуктивності тепер виправлено. Встановлення з використанням фільтрів мають бути такими ж швидкими або швидшими, ніж повне встановлення, див #10408.

Зміни в патчах​

• Не додавати символічне посилання на проєкт до реєстру проєктів сховища, якщо сховище знаходиться у вкладеній теці проєкту, див. #10411.
• Має бути можливість оголосити параметр requiredScripts у pnpm-workspace.yaml, див. #10261.

pnpm 10.27 додає нове налаштування для ігнорування перевірок політики довіри для старих версій пакунків, вводить реєстр проєктів для глобального очищення віртуального сховища та включає кілька виправлень помилок.

Незначні зміни​

trustPolicyIgnoreAfter​

Додавання trustPolicyIgnoreAfter дозволяє ігнорувати перевірки політики довіри для пакунків, опублікованих пізніше, ніж зазначений час, див. #10352.

Global Virtual Store Improvements​

Додано реєстр проєктів для підтримки скорочення глобального віртуального сховища.

Проєкти, що використовують сховище, тепер реєструються через символічні посилання у {storeDir}/v10/projects/. Це дозволяє pnpm store prune відстежувати, які пакунки все ще використовуються активними проєктами, та безпечно видаляти невикористовувані пакунки з глобального віртуального сховища.

Напів-порушення. Змінено розташування пакетів без області дії у віртуальному глобальному сховищі. Тепер вони будуть зберігатися в теці з назвою @, щоб зберегти однакову глибину ієрархії тек у 4 рівні.

Додано збірку сміття за принципом «позначення та очищення» для глобального віртуального сховища.

pnpm store prune тепер видаляє невикористовувані пакунки з теки links/ глобального віртуального сховища. Алгоритм:

1. Сканує всі зареєстровані проєкти на наявність символічних посилань, що вказують на сховище
2. Проходить перехідні залежності, щоб позначити доступні пакунки
3. Видаляє будь-які теки пакунків, не позначені як доступні

Це включає підтримку монорепозиторіїв робочого простору — скануються всі теки node_modules у межах проєкту (включно з тими, що містяться в пакунках робочого простору).

Зміни в патчах​

• Видаємо помилку, якщо значення параметра tokenHelper або <url>:tokenHelper містить змінну середовища.
• Залежності Git зі скриптами збірки повинні враховувати налаштування dangerouslyAllowAllBuilds #10376.
• Пропустити перевірку менеджера пакунки під час запуску з --global, якщо налаштовано проєкт packageManager, і попередити, що перевірку пропущено.
• Команда pnpm store prune не повинна завершуватися помилкою, якщо тека кешу dlx містить файли, а не лише теки #10384
• Виправлено помилку (#9759), через яку команда pnpm add неправильно змінювала запис теки в pnpm-workspace.yaml на його точну версію.

2025 рік став переломним для pnpm. Хоча нашою основною метою було переосмислення моделі безпеки управління пакунками, ми також досягли значного поліпшення продуктивності та зручності роботи розробників.

Від стандартного блокування скриптів життєвого циклу до впровадження глобального віртуального сховища — ось огляд основних функцій, реалізованих у 2025 році.

Використання​

Згідно зі статистикою завантажень, pnpm було завантажено вдвічі більше, ніж у 2024 році!

Редизайн головної сторінки​

Ви, можливо, помітили, що ми змінили дизайн нашої головної сторінки! Цей редизайн став можливим завдяки нашому найвидатнішому спонсору, Bit.cloud.

Нова головна сторінка тепер створена за допомогою компонентів Bit, і значна частина роботи була виконана за допомогою агента штучного інтелекту Bit: Hope AI. У нас навіть є власна система дизайну тепер.

Презентація на JSNation​

Цей рік став для мене важливим етапом, оскільки я вперше виступив з доповіддю на великій міжнародній конференції: JSNation, яка відбулася в червні в Амстердамі. Я хотів би подякувати команді JSNation за цю чудову можливість!

Я був приємно здивований, наскільки добре відомий pnpm у спільноті та скільки людей використовують його в роботі!

Моя презентація була про залежності конфігурації, і ви можете переглянути запис тут.

Основні функції​

Тепер заглибмось в найважливіші зміни, що з'явилися в pnpm v10 протягом 2025 року.

Безпека як стандарт​

Найзначнішим зрушенням цього року став перехід pnpm до «Безпеки як стандарт». У pnpm версії 10.0 ми перестали неявно довіряти встановленим пакункам.

Блокування скриптів життєвого циклу (v10.0)​

Протягом багатьох років команда pnpm install означала довіру до всього дерева залежностей для виконання довільного коду. У версії 10 цю функцію було вимкнено. pnpm більше стандартно не запускає скрипти preinstall або postinstall, що усуває величезну кількість векторів атак на ланцюжок постачання.

Щоб удосконалити цей контроль, ми ввели allowBuilds у v10.26, замінивши попередній onlyBuiltDependencies більш гнучкою конфігурацією:

allowBuilds:
  esbuild: true
  # Дозволити лише конкретні версії
  nx@21.6.4: true

Ешелонований захист (v10.16 та v10.21)​

Але ми не зупинилися лише на скриптах. Ми додали рівні захисту, щоб виловлювати шкідливі пакунки ще до того, як вони досягнуть вашого диска:

• minimumReleaseAge: Блокує релізи "zero-day" (наприклад, пакунки, випущені менше ніж 24 години тому), даючи спільноті час позначити шкідливі оновлення.
• trustPolicy: no-downgrade: Запобігає встановленню оновлень, які мають гіршу репутацію, ніж попередні версії (наприклад, версія, опублікована без перевірки CI/CD).
• blockExoticSubdeps: Запобігає завантаженню перехідних залежностей з ненадійних джерел довіреними залежностями.

Глобальне віртуальне сховище (v10.12)​

Одним з оригінальних нововведень pnpm було сховище з адресацією контенту, яке заощаджує місце на диску шляхом дедуплікації файлів. У версії 10.12 ми пішли далі з Global Virtual Store.

Раніше проєкти мали власну структуру node_modules. Завдяки enableGlobalVirtualStore: true, pnpm тепер може безпосередньо повʼязувати залежності з центрального розташування на диску з вашим проєктом. Це означає:

1. Значна економія місця на диску: однакові графи залежностей використовуються в усіх проєктах.
2. Швидше встановлення: Якщо у вас є 10 проєктів, що використовують react@19, pnpm потрібно лише один раз глобально підключити їх.

Нативна підтримка JSR (v10.9)​

Ми взяли на озброєння новий реєстр JSR з нативною підтримкою. Тепер ви можете встановлювати пакунки безпосередньо з JSR, використовуючи протокол jsr::

pnpm add jsr:@std/collections

Це коректно відображається в package.json та безперешкодно обробляє унікальні правила розвʼязання JSR-пакунків разом із вашими залежностями npm.

Конфігураційні залежності (v10.0)​

Для монорепозиторіїв та складних налаштувань ми ввели Конфігураційні залежності. Ця функція дозволяє ділитися та консолідувати конфігурацію pnpm, таку як хуки, патчі та дозволи на збірку, між декількома проєктами.

Конфігураційні залежності встановлюються в node_modules/.pnpm-config до обробки основного графа залежностей. Це означає, що ви можете використовувати їх для:

• Спільне використання хуків .pnpmfile.cjs між репозиторіями.
• Централізувати файли патчів для patchedDependencies.
• Підтримувати спільний список пакунків, яким дозволено виконувати скрипти збірки для allowBuilds.

configDependencies:
  pnpm-plugin-my-company: "1.0.0+sha512-..."

Це гарантує, що ваша конфігурація pnpm має версії, є узгодженою та доступною саме тоді, коли це потрібно менеджеру пакунків.

Автоматичне управління JavaScript Runtime (v10.14 & v10.21)​

Ми вже деякий час підтримуємо керування середовищем виконання Node.js. У 2025 році ми розширили цю функцію, щоб підтримати інші середовища виконання, такі як Deno та Bun.

Тепер ви можете вказати потрібне середовище виконання в package.json через devEngines.runtime:

{
  "devEngines": {
    "runtime": {
      "name": "node",
      "version": "24.6.0"
    }
  }
}

pnpm автоматично завантажить та використовуватиме цю конкретну версію середовища виконання для запуску скриптів у цьому проєкті. Це робить фразу «Працює на моїй машині» реліктом минулого — всі члени команди використовують однакове середовище виконання, яке повністю управляється pnpm.

Що далі​

Ми вже почали працювати над pnpm v11.0, яка має деякі помітні покращення продуктивності. Глобальне віртуальне сховище ще не є стандартно увімкненим. Ми працюватимемо над виправленнями помилок та відсутніми функціями, щоб потенційно зробити його стандартно увімкненим у майбутньому основному випуску.

pnpm 10.26 вводить більш суворі стандартні налаштування безпеки для залежностей, що розміщуються на git, додає allowBuilds для детальних дозволів на виконання скриптів та включає нове налаштування для блокування екзотичних перехідних залежностей.

Незначні зміни​

Суворіша безпека залежностей Git​

Напів-порушення. Залежність, що розміщена на Git, тепер блокується від виконання скриптів prepare під час інсталяції, якщо це не дозволено явно в onlyBuiltDependencies (або allowBuilds) #10288. Ця зміна запобігає виконанню шкідливого коду з ненадійних репозиторіїв git.

allowBuilds​

Додано новий параметр allowBuilds, який забезпечує гнучкий спосіб керування скриптами збірки. Він приймає набір відповідників пакунків, щоб явно дозволити (true) або заборонити (false) виконання скрипту. Це замінює onlyBuiltDependencies та ignoredBuiltDependencies як бажаний метод конфігурації #10311.

Приклад:

allowBuilds:
  esbuild: true
  core-js: false
  nx@21.6.4 || 21.6.5: true

blockExoticSubdeps​

Додано нове налаштування blockExoticSubdeps для підвищення безпеки ланцюга постачання. При встановленні значення true запобігає обробці екзотичних протоколів (таких як git+ssh: або безпосередньо https: tar-архівів) у перехідних залежностях. Тільки прямим залежностям дозволено використовувати екзотичні джерела #10265.

Хеш цілісності для HTTP-архівів​

Напів-порушення. pnpm тепер обчислює хеш цілісності для залежностей HTTP tar-архівів під час їх завантаження та зберігає його у файлі блокування. Це гарантує, що сервери не зможуть надавати змінений вміст під час наступних інсталяцій без належного виявлення #10287.

pnpm pack --dry-run​

Додано підтримку --dry-run до команди pack. Це дозволяє перевірити, які файли будуть включені до tar-архіву, без його фактичного створення #10301.

Зміни в патчах​

• Показати застарівання у форматі таблиці/списку, коли остання версія є застарілою #8658.
• Видалення налаштування injectWorkspacePackages із файлу блокування в команді deploy #10294.
• Нормалізація URL-адреси архівів tar перед збереженням їх у файлі блокування #10273.
• Виправлено нормалізацію URL-адрес для перенаправлених незмінних залежностей #10197.

pnpm 10.25 покращує обробку сертифікатів, додає базовий pnpm init та містить кілька виправлень, що покращують якість роботи.

Незначні зміни​

Сертифікати для кожного реєстру​

Тепер ви можете завантажувати вбудовані сертифікати з налаштувань cert, ca та key для конкретних URL-адрес реєстру (наприклад, //registry.example.com/:ca=-----BEGIN CERTIFICATE-----...). Раніше pnpm враховував лише записи certfile, cafile та keyfile. Це приводить pnpm у відповідність до поведінки npm .npmrc #10230.

pnpm init --bare​

Додано прапорець --bare до pnpm init для створення package.json лише з обовʼязковими полями #10226.

Зміни в патчах​

• Покращено звітування про ігноровані скрипти залежностей #10276.
• pnpm install тепер збирає будь-які залежності, які були додані до onlyBuiltDependencies, але ще не запустили свої збірки #10256.
• Команда pnpm publish -r --force опублікує версію, навіть якщо вона вже існує в реєстрі, що відповідає наміру прапорця #10272.
• Запобігання помилкам ERR_PNPM_MISSING_TIME, коли пакунок, виключений з перевірок політики довіри, не має поля time у своїх метаданих.

We got lucky with Shai-Hulud 2.0.

In November 2025, a self-replicating npm worm compromised 796 packages with 132 million monthly downloads. The attack used preinstall scripts to steal credentials, install persistent backdoors, and in some cases wipe entire developer environments. We weren't affected—not because we had robust defenses, but because we didn't run npm install or npm update during the attack window.

Luck isn't a security strategy.

Who We Are​

I'm Ryan Sobol, Principal Software Engineer at the Seattle Times. We've been using npm as our default package manager for years, with some brief experimentation with Yarn that never gained traction. Now we're piloting pnpm specifically for its client-side security controls that complement the registry-level improvements npm has been rolling out.

Trust is paramount for news organizations, especially these days. A supply chain compromise could expose customer data, employee credentials, production infrastructure, and source code—all things that could take weeks to recover from and potentially require breach notifications to our readers. We understand how expensive these incidents can be in both time and money. That's a path we don't want to go down.

Despite the organizational inertia that comes with sticking to npm, we think pnpm has a real chance here. It's a true drop-in replacement—same commands, same workflows, same registry. That makes the transition achievable in a way previous alternatives weren't.

This isn't a polished case study. It's a real-world data point from a team that's just starting to figure out supply chain security. The challenges we're encountering and how we're thinking about these controls might be useful as you consider implementing them yourself.

Why Client-Side Controls Matter​

npm has made tremendous progress on supply chain security. Trusted publishing, provenance attestations, and granular access tokens are all significant improvements that make it substantially harder to publish malicious packages after compromising maintainer accounts.

But here's the gap: these registry improvements protect the publishing side. They don't prevent consuming malicious packages.

When you run npm install or npm update, lifecycle scripts (e.g., preinstall and postinstall) execute arbitrary code from the internet with full developer privileges—before the package has been evaluated for safety. These scripts can access your credentials (npm, GitHub, AWS, databases), your source code, your cloud infrastructure, and your entire filesystem.

This is the fundamental vulnerability that attacks like Shai-Hulud exploit. Even with these registry improvements, if a legitimate maintainer's account is compromised, attackers can publish a version with malicious lifecycle scripts that execute immediately upon installation—before the community detects the compromise.

That's why we felt we needed defense on both sides: npm's improvements make it harder to publish malicious packages; pnpm's client-side controls make it harder to consume them. These approaches are complementary, not competitive. pnpm uses npm's registry and benefits from all of npm's security improvements while adding an additional layer of protection on the client side.

This is defense-in-depth.

The Three Layers We're Using​

For our pilot, we're using three pnpm security controls that work together. Each control addresses a different attack vector, and each has escape hatches for legitimate exceptions. We knew going in that we'd need those exceptions—the real world is messy.

Control 1: Lifecycle Script Management​

One of the main reasons we considered pnpm was learning that it blocks lifecycle scripts by default. Unlike other package managers, it doesn't implicitly trust and execute arbitrary code from packages.

In practice, when a package has preinstall or postinstall scripts, pnpm blocks them but installation continues with a warning. This already provides significant protection—malicious scripts won't execute without you explicitly allowing them. However, we were concerned that warnings would be too easy to ignore, especially since installation appears to succeed. We wanted stricter control with strictDepBuilds: true:

strictDepBuilds: true

onlyBuiltDependencies:
  - package-with-necessary-build-scripts

ignoredBuiltDependencies:
  - package-with-unnecessary-build-scripts

By "necessary," we mean packages that genuinely need their lifecycle scripts to function—things like native extensions that compile from source or database drivers that link against platform-specific libraries. By "unnecessary," we mean scripts that are optional optimizations or setup steps that don't affect whether the package functions in our use case.

With strictDepBuilds: true, installation fails immediately when it encounters lifecycle scripts, forcing us to:

1. Identify which packages have lifecycle scripts—pnpm tells you exactly which ones
2. Research what each script does, which can be as easy as feeding the self-contained preinstall or postinstall script into a generative AI for interpretation
3. Use human judgment to make a conscious, documented decision about whether to allow or block it

For our team, this ensures we're making deliberate choices upfront rather than potentially discovering issues later.

Note: The pnpm team is considering making strictDepBuilds: true the default behavior in v11, and is also exploring clearer naming for the allow/deny syntax based on feedback from teams implementing these controls in practice.

Control 2: Release Cooldown​

This control blocks installation of package versions published within a cooldown period. The idea is to give the community time to detect and remove malicious packages before they reach your environment.

minimumReleaseAge: <duration-in-minutes>

minimumReleaseAgeExclude:
  - package-with-critical-hotfix@1.2.3

Our mindset shift: We had to retrain ourselves to stop thinking "newest is best." What we're learning is that from a supply chain security perspective, that's not always the case—slightly older can often be safer. A package that's been available for a period of time gives the community and security researchers time to detect potential issues.

Looking at recent attacks, malicious packages have been detected and removed in varying timeframes. The September 2025 npm supply chain attack that compromised debug, chalk, and 16 other packages saw removal within about 2.5 hours, while Shai-Hulud 2.0 (November 2025) took about 12 hours. Every attack is different and every recovery timeline will vary, but the appropriate cooldown period depends on your organization's risk tolerance—it could be measured in hours, days, or weeks. Either way, a cooldown period would have blocked these attacks.

The trade-off we accepted: Given the scale of our organization and our priorities, we're not always on the absolute latest versions of packages—despite best efforts. So this cooldown policy aligns more with our reality than it disrupts it. When we genuinely need a newer version (critical security patches, breaking bugs), we can temporarily exempt it after review.

Control 3: Trust Policy​

This control blocks installation when a package version has weaker authentication than previously published versions—often a sign that an attacker compromised maintainer credentials and published from their own machine instead of the official CI/CD pipeline.

trustPolicy: no-downgrade

trustPolicyExclude:
  - package-that-migrated-cicd@1.2.3

How it works: npm tracks three trust levels for published packages (strongest to weakest):

1. Trusted Publisher: Published via GitHub Actions with OIDC tokens and npm provenance
2. Provenance: Signed attestation from a CI/CD system
3. No Trust Evidence: Published with username/password or token authentication

If a newer version has weaker authentication than an older version, installation fails. For example, if v1.0.0 was published with Trusted Publisher but v1.0.1 was published with basic auth, pnpm blocks v1.0.1.

In the s1ngularity attack in August 2025, attackers compromised maintainer credentials and published malicious versions from their own machines. Because they didn't have CI/CD access, the malicious versions had no provenance—a clear trust downgrade. This control would have blocked installation.

When trust downgrades might be legitimate: New maintainer who hasn't set up provenance yet, CI/CD system migration, emergency hotfix published manually while CI/CD was down. In these cases, we'd investigate why the trust level decreased, verify it's safe, then add to trustPolicyExclude.

Note: This feature was added to pnpm in November 2025 and is quite new. We're still learning how often legitimate trust downgrades occur in practice.

How They Work Together: The React Example​

We don't see any of these controls as a silver bullet. They work as layers of defense—when we need to make an exception for one control, the other layers continue protecting us.

Let's look at a real scenario: the critical React vulnerability disclosed in December 2025.

This was a serious security issue that required immediate patching. Normally, our release cooldown would prevent us from installing a package version published so recently. But this was a critical security patch—we couldn't wait.

Here's how the layered defense would work in this scenario:

What you'd do: Add the specific React version to minimumReleaseAgeExclude after reviewing the vulnerability disclosure and verifying the patch was legitimate.

What still protects you:

• Lifecycle Script Management is still active—if an attacker had injected malicious lifecycle scripts into the React patch, they would be blocked (React normally has no lifecycle scripts, so any scripts would be immediately suspicious)
• Trust Policy is still active—if an attacker had compromised React's publishing credentials and pushed a malicious "patch" from their own machine, the trust downgrade would be blocked

This is why we think exceptions are expected and okay. You make a conscious, documented decision to bypass one control for a legitimate reason, but you still have robust protection from the other layers. No single point of failure.

This is what defense-in-depth looks like in practice for us.

Our Pilot Experience​

We implemented all three security controls in one of our backend services as a proof of concept. Total setup time: a few hours to research, understand, and define our approach.

During setup, pnpm identified three packages with lifecycle scripts:

• esbuild: Optimizes CLI tool startup by milliseconds—not needed since we only use the JavaScript API
• @firebase/util: Auto-configures client SDK—not needed since we only use the server SDK
• protobufjs: Checks version schema compatibility—not needed since it's a transitive dependency

We researched what each script did (reading documentation and feeding the scripts to AI for interpretation), determined none were necessary for our use case, and blocked them. Zero impact on functionality.

That was it. A few hours of initial investment for ongoing protection against Shai-Hulud-style attacks.

What the friction feels like: These controls create friction by design—and for us, that's a feature, not a bug. The friction forces conscious decisions about what code runs in our environment rather than implicitly trusting everything. When new dependencies have scripts, we anticipate it will take around 15 minutes to review and document the decision.

We expect that the friction will become more intuitive with practice as we get more familiar with the process.

What We're Learning​

A few things we've learned from our pilot:

The defense-in-depth model actually works. Having multiple layers on the client side—plus the benefits from npm's publishing-side improvements—means we can be pragmatic about exceptions. When we need to bypass one control for a legitimate reason, the others are still protecting us. This removes the anxiety of making exceptions—they're not security failures, they're the system working as designed.

The mental model takes time. There's a learning curve to thinking "security-first" rather than "convenience-first." But once the mental model clicks—that slightly older packages are safer, that explicit decisions are better than implicit trust—the workflow feels natural.

These controls are practical for mid-sized teams. We're not a large tech company with a dedicated security team. We're a mid-sized news media organization with limited engineering resources. If we can implement these controls successfully, they're accessible to most teams.

We're still learning. The threat landscape evolves, and our approach will too. The trust policy feature is only a few weeks old, and we don't yet know how often legitimate trust downgrades will occur in practice. We're planning to expand these controls to other codebases in the near future, which will give us more data on how they scale with applications with different dependency graphs.

For Other Teams Considering This​

If you're considering pnpm's security controls, here's what worked for us:

Start with one project. Piloting on a single codebase first let us get comfortable with the workflow, understand the friction points, and build confidence before considering a broader rollout.

Plan for exceptions upfront. Go in expecting you'll need exceptions for lifecycle scripts (packages that need compilation), release cooldowns (critical security patches), and trust downgrades (CI/CD migrations). This isn't failure—it's how the system is designed to work.

Use strictDepBuilds: true from day one. Relying on warnings felt too risky for us. We wanted installation to fail immediately and force the decision. This prevents packages from potentially misbehaving later and ensures deliberate choices.

Document every exception. Write down why you allowed a lifecycle script or exempted a package. This creates an audit trail, helps future team members understand the reasoning, and makes it easy to clean up exceptions later.

Trust the layers. When you make an exception for one control, remember the other two are still protecting you. The defense-in-depth model gives you room to be pragmatic.

Share Your Experience​

We'd love to hear from other teams implementing these controls or considering them. What's working? What's challenging? What have you learned? Join the conversation in the pnpm GitHub Discussions or share your experiences on social media—we're all learning together.

Thank You​

Thanks to the pnpm team for building these controls and for the thoughtful way they've approached making them both powerful and practical. And thanks for inviting us to share our story.

The work you're doing matters. These controls provide real protection that complements npm's registry improvements. Together, they give teams like ours a fighting chance against increasingly sophisticated supply chain attacks.

Ryan Sobol is a Principal Software Engineer at the Seattle Times, where he works on mobile and web development, cloud infrastructure, and developer tooling. The views expressed here are his own and based on the Seattle Times' pilot implementation of pnpm's security controls.

pnpm тепер автоматично масштабує мережевий паралелізм на машинах з великою кількістю ядер і містить кілька виправлень для підвищення надійності.

Незначні зміни​

Адаптивний мережевий паралелізм​

Мережевий паралелізм тепер автоматично масштабується в діапазоні від 16 до 64 на основі кількості робочих процесів pnpm (робочі процеси × 3). Це збільшує пропускну здатність на машинах з великою кількістю ядер процесора, зберігаючи при цьому передбачуване використання ресурсів на менших конфігураціях #10068.

Зміни в патчах​

• trustPolicy тепер ігнорує підтвердження довіри з попередніх версій під час встановлення не попередньої версії, тому довірена попередня версія не може блокувати встановлення стабільної версії, якій бракує підтвердження довіри.
• Обробка помилок ENOENT, що виникають у функції fs.linkSync(), які можуть траплятися в контейнерних середовищах (OverlayFS) замість EXDEV. pnpm тепер коректно повертається до fs.copyFileSync() у цих випадках #10217.
• Скасовано: pnpm self-update завантажує pnpm з налаштованого реєстру npm #10205.
• Пакунки, які не мають файлу package.json (як-от Node.js), більше не імпортуються повторно зі сховища під час кожного встановлення. pnpm тепер перевіряє додатковий файл для перевірки пакунка в node_modules.
• Правильне зчитування токенів автентифікації для URL-адрес, що містять підкреслення #17.

Додано опцію --lockfile-only до pnpm list та різні покращення до pnpm self-update.

Незначні зміни​

pnpm list --lockfile-only​

Додано опцію --lockfile-only до pnpm list #10020.

Якщо вказано, pnpm list буде зчитувати інформацію про пакунки з файлу блокування замість перевірки фактичної теки node_modules. Це корисно для швидкої перевірки того, що буде встановлено, без необхідності повної установки.

Зміни в патчах​

• Команда pnpm self-update має завантажити pnpm з налаштованого реєстру npm #10205.
• pnpm self-update завжди повинен встановлювати невиконуваний пакунок pnpm (pnpm у реєстрі) і ніколи пакунок @pnpm/exe під час встановлення v11 або новішої версії. Наразі ми не можемо надсилати @pnpm/exe, оскільки pkg не працює з ESM #10190.
• Node.js runtime не додається до "dependencies" у pnpm add, якщо в package.json оголошено налаштування engines.runtime #10209.
• Інсталяція має завершитися невдачею, якщо додаткову залежність неможливо встановити через помилку перевірки політики довіри #10208.
• pnpm list та pnpm why тепер показують протокол npm: для пакунків з аліасами (наприклад, foo npm:is-odd@3.0.1) #8660.
• Не додавати зайву скісну риску до URL-адреси дзеркала Node.js #10204.
• pnpm store prune не повинно завершуватися невдачею, якщо сховище містить пакунки Node.js #10131.

Додано підтримку виключення пакунків із політики довіри та перевизначення поля engines під час публікації.

Незначні зміни​

Винятки з політики довіри​

Додано підтримку для trustPolicyExclude.

Тепер ви можете вказати один або кілька конкретних пакунків або версій, які pnpm повинен дозволити встановлювати, навіть якщо ці пакунки не відповідають вимогам політики довіри. Наприклад:

trustPolicy: no-downgrade
trustPolicyExclude:
  - chokidar@4.0.3
  - webpack@4.47.0 || 5.102.1

Див. тікет: #10164

Перевизначення поля engines при публікації​

Дозволяє замінити поле engines при публікації значенням поля publishConfig.engines.

Це дозволяє вказати для опублікованого пакунка інші вимоги до рушія, ніж ті, що використовуються під час розробки.

Зміни в патчах​

• Запобігання збою, коли два процеси pnpm одночасно створюють жорсткі посилання на вміст теки в одне й те саме місце призначення #10179.

Додано підтримку встановлення середовища виконання Node.js для залежностей та налаштування політики довіри.

Незначні зміни​

Встановлення середовища виконання Node.js для залежностей​

Додано підтримку автоматичного встановлення середовища виконання Node.js для залежностей. pnpm тепер встановить версію Node.js, необхідну для залежності, якщо ця залежність оголошує середовище виконання Node.js у полі engines.runtime. Наприклад:

{
"engines": {
  "runtime": {
    "name": "node",
    "version": "^24.11.0",
    "onFail": "download"
  }
}
}

Якщо пакунок із залежностями середовища виконання Node.js є CLI-застосунком, pnpm прив’яже CLI-застосунок до необхідної версії Node.js. Це гарантує, що незалежно від глобально встановленого екземпляра Node.js, CLI буде використовувати сумісну версію Node.js.

Якщо пакунок містить скрипт postinstall, цей скрипт буде виконано з використанням вказаної версії Node.js.

Див. PR: #10141

Політика довіри​

Додано новий параметр: trustPolicy.

При встановленні значення no-downgrade pnpm видасть помилку, якщо рівень довіри до пакунка знизився порівняно з попередніми версіями. Наприклад, якщо пакунок раніше був опублікований надійним видавцем, але зараз має лише походження або не має доказів надійності, встановлення не відбудеться. Це допомагає запобігти встановленню потенційно небезпечних версій.

Див. тікет: #8889.

Інші функції​

• Додано підтримку команди pnpm config get globalconfig для отримання шляху до файлу глобальної конфігурації #9977.

Зміни в патчах​

• Коли користувач запускає pnpm update для залежності, яка безпосередньо не вказана в package.json, жодна з прямих залежностей не повинна оновлюватися #10155.
• Запобігання збою, коли два процеси pnpm одночасно створюють жорсткі посилання на вміст теки в одне й те саме місце призначення #10160.
• Налаштування gitBranchLockfile та пов'язаних з ним параметрів через pnpm-workspace.yaml має працювати #9651.

У цьому випуску додано прапорець --all для команди pnpm help, щоб виводити всі команди.

Незначні зміни​

pnpm help --all​

Додано підтримку опції --all у pnpm help для перегляду всіх команд #8628.

Зміни в патчах​

• Якщо latest версія не відповідає вимогам зрілості, налаштованим за допомогою minimumReleaseAge, виберіть найвищу версію, яка є достатньо зрілою, навіть якщо вона має іншу основну версію #10100.
• Команда create не повинна перевіряти інформацію про патч.
• Встановіть для managePackageManagerVersions значення false під час перемикання на іншу версію інтерфейсу командного рядка pnpm, щоб уникнути подальших перемикань #10063.