Passa al contenuto principale

pnpm 11.6

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

pnpm 11.6 adds a file-free way to supply registry authentication through npm_config_//… and pnpm_config_//… environment variables, raises the default network concurrency, and skips full re-resolution when only pnpm-lock.yaml is missing. It also infers platform fields for optional dependencies so foreign-platform binaries are never downloaded.

Minor Changes​

File-free registry auth via environment variables​

You can now configure URL-scoped registry settings through npm_config_//… and pnpm_config_//… environment variables, with no .npmrc file at all:

export "pnpm_config_//registry.npmjs.org/:_authToken=$NPM_TOKEN"

Because the registry a value applies to is encoded in the (trusted) environment variable name, it is host-scoped by construction and cannot be redirected to another registry by repository-controlled config. The environment value is treated as trusted config: it takes precedence over a project/workspace .npmrc but is still overridden by command-line options. When the same key is provided through both prefixes, pnpm_config_ wins.

This is the most direct replacement for a committed //registry.npmjs.org/:_authToken=${NPM_TOKEN} line, whose ${...} placeholders are no longer expanded in a project .npmrc since v11.5.3. See Environment variables in auth settings.

Higher default network concurrency​

The default network concurrency was raised from min(64, max(cpuCores * 3, 16)) to min(96, max(cpuCores * 3, 64)). Package downloads are I/O-bound, not CPU-bound, so deriving the floor from the core count left machines with few cores (for example 4-vCPU CI runners) downloading only 16 tarballs at a time and unable to saturate a low-latency registry. The networkConcurrency setting still overrides the default.

No re-resolution when only the lockfile is missing​

pnpm install now completes without re-resolving when pnpm-lock.yaml was deleted but node_modules is intact. The up-to-date check treats the current lockfile (node_modules/.pnpm/lock.yaml) — the record of what the previous install materialized — as the wanted lockfile, verifies the manifests still match it, restores pnpm-lock.yaml from it, and reports "Already up to date". Previously this triggered a full resolution and a re-verification of every locked package against the registry.

Patch Changes​

  • Platform-specific optional dependencies are now skipped even when their os / cpu / libc fields are missing from the registry metadata or the lockfile. Some registries strip these fields, which made pnpm download and install the binaries of every platform regardless of supportedArchitectures. The missing fields are now inferred from the package name (e.g. @nx/nx-win32-arm64-msvc → os: win32, cpu: arm64), so foreign-platform binaries are skipped without even downloading them (#11702).
  • Improved the warning printed when a project .npmrc uses an environment variable in a registry/proxy URL or in registry credentials. The message now explains why the setting was ignored and how to migrate it to a trusted source — for example by moving the line to the user-level ~/.npmrc or running pnpm config set "<key>" <value> — with a link to https://pnpm.io/npmrc. The pnpm config set example is only suggested when the key has no ${...} placeholder, so the snippet is always safe to copy-paste.
  • Print a "Lockfile passes supply-chain policies (verified 2h ago)" message when lockfile verification is skipped because a cached verdict for the same lockfile content and policy is reused. Previously the cached short-circuit was completely silent, which made it look like the policy gate never ran (#12324).