pnpm

pnpr 0.1.0-alpha.18 keeps hosted package metadata in SQLite or a shared libSQL database, logs release records in transparency logs, and accepts packages with platform variants. The documents metadata backend is gone, so packages hosted by an earlier pnpr have to be published again.

Minor Changes

Metadata storage

• pnpr now keeps hosted package metadata in SQL only. By default it uses a SQLite database at <storage>/.metadata/metadata.sqlite. The metadata block names another database by URL, such as url: sqlite:./metadata.sqlite. The documents metadata backend is removed, and a config that sets metadata.backend or metadata.path is refused.

  pnpr does not import the metadata of an existing store. A store that kept its metadata as documents starts with empty metadata, so republish its packages after upgrading. An s3: store that hosts packages needs a libSQL metadata.url. migrate-storage moves archives only and needs that libSQL database to hold the metadata already.

• pnpr can keep hosted package metadata in a libSQL database, such as Turso, shared by several pnpr instances. Set metadata.url to a libsql:// URL. It works with an s3: block, so archives stay in object storage. With metadata.replicaPath, each instance reads package documents from a local replica that syncs every metadata.syncInterval. Permission checks and the reads a write depends on always read the primary.

• pnpr refuses any change to a published npm version's manifest, and never accepts an unpublished version again. pnpr records who moved each dist-tag, and when. Hosted npm package responses carry a pnpr-generation header.

• A reader sees all of a publish or batch publish, or none of it. A retried publish gets its original response instead of a 409. Batch publishes accept an Idempotency-Key header. pnpr records each publish as a publication and serves it at /-/publications/<org>/<id-or-name>.

• pnpr stores release notes for package versions and publications. A publish can include them in a notes field. Publishers can edit or delete a note later. npm clients read a version's note at /npm/<name>/<version>/notes. A package's notes are listed at /npm/<name>/-/notes. A publication's note is at /-/publications/<org>/<id-or-name>/notes.

Publishing

• A hosted pnpr registry rejects a publish whose version metadata disagrees with the package.json inside its archive. Its 400 response names the package, the version, and each differing field. pnpr checks the dependencies, the platform fields, bin, and the install scripts. pnpr also rejects a publish whose archive does not decode or holds more than one package.json.

  pnpr accepts the rewrites that npm and older clients make while publishing, such as a bin string expanded into an object. pnpr publishes a version without semver build metadata. pnpr serves a version's checked fields as its archive states them, with hasInstallScript and _hasShrinkwrap always set. Other fields, such as description, are served as submitted.

• pnpr accepts release archives uploaded by integrity before the publish that references them, through PUT /-/pnpr/v0/artifacts/blob?integrity=<sha512-…> without an owner #17608. An npm publish, alone or in a batch, can then reference a staged archive: the attachment carries the archive's integrity in place of data. A version and its platform variants therefore no longer have to fit in one request body. An archive the publishing account has not staged, or one that has expired, fails the whole publish.

• Trusted-publishing workload credentials can stage archives for the packages they are configured for, and send batch publish commits for those packages. A batch entry for any other package, or of another ecosystem, is refused.

• A hosted registry that declares tarballs: tar now stores each published version as one tar compressed with zstd at level 19

pnpm 11.28.11 fixes frozen installs with excludeLinksFromLockfile, pnpm link in workspaces, pnpm deploy with dangling symlinks, and verifyDepsBeforeRun starting needless installs.

Patch Changes

Installing packages

• pnpm deploy now keeps a symlink in the project whose target is missing from the source, such as a link into a node_modules directory that was removed after the build. Deploy used to fail with ENOENT on such a link #17571.

• A package with bundledDependencies and a build script now keeps its bundled dependencies when it is restored from the side-effects cache #17523.

• pnpm install now links the runtime that an earlier pnpm install --no-runtime skipped #17542.

• Commands of a package whose bin paths contain excess parent directory segments, such as ../dist/cli.js, are no longer missing. Such paths now resolve inside the package #17586.

• Generated POSIX shell shims now quote their paths, so shell special characters in a path stay literal.

• A repeat pnpm install now rewrites the bin shims after extendNodePath changes. Before, it reported "Already up to date" and the shims kept the NODE_PATH of the previous setting.

Lockfile and resolution

• pnpm install --frozen-lockfile now accepts the lockfile it wrote with excludeLinksFromLockfile and linkWorkspacePackages on, when a project depends on a workspace package through a plain version range or a catalog: entry. It used to fail with ERR_PNPM_OUTDATED_LOCKFILE.

• pnpm install --frozen-lockfile, pnpm approve-builds, and pnpm rebuild now accept a lockfile that resolves a * dependency to a prerelease latest version. pnpm wrote such a lockfile and then reported it as outdated #17594.

• Packages from the default registry keep plain lockfile keys, even when a prefix such as npmjs points at the registry set as registry. A dependency written with such a prefix shares the plain entry of the same package. The next install rewrites keys that earlier versions qualified this way #17575.

• Relative local paths in root overrides now resolve from the workspace root when each project has its own lockfile #17691.

  Installing a local directory dependency no longer fails when another project's install is writing a lockfile in that directory.

• Peer deduplication no longer gives a project different copies of a dependency across direct and transitive paths when an optional peer has no provider #17666.

• A Node.js version range such as >=26.13, for example in devEngines.runtime, now resolves to the newest stable release that satisfies it. pnpm picks a prerelease only when no stable release matches #17516.

verifyDepsBeforeRun

• With verifyDepsBeforeRun, pnpm run and pnpm exec now report dependencies as out of date after a dependency is added to the package.json of a local directory dependency, such as "lib": "file:../lib". Before, the command ran without the new dependency installed.

• verifyDepsBeforeRun no longer reports dependencies as out of sync when only the version field of a single-project repository changed #17560. The same holds for a workspace project that no dependency can resolve to. A script run after such a change no longer starts an install first.

pnpm link

• In a workspace, pnpm link <dir> now adds the link: dependency to the package.json of the project where the command runs, not to the workspace root's package.json. The link is created in that project's node_modules

pnpm 11.28.10 stops pnpm store prune from deleting other stores when cacheDir points to their parent directory. It also fixes globally installed commands that load hoisted dependencies, and repeat installs that missed changes to local dependencies.

Patch Changes

Installing packages

• pnpm store prune preserves other stores and global package data when cacheDir points to their parent directory.

• Commands installed with pnpm add --global now find the dependencies that pnpm hoists for their package. A package that loads a dependency it does not declare, such as a native addon's platform-specific package, failed with "Cannot find module". Reinstall such a package with pnpm add --global to update its existing command #17503.

• pnpm prune --prod no longer fails with ERR_PNPM_EXDEV when node_modules was copied from an earlier Docker build stage #17424.

• pnpm install now retries a Node.js runtime zip download when the connection drops partway through. A download that still fails names its URL. Before, a single dropped connection ended the install with terminated #17411.

• With the global virtual store, a change to a dependency of one package in a dependency cycle now gives every package in that cycle a new directory. Before, the other packages kept their directories and still linked the old copy of the changed package, so the project could load two copies of it #17466.

  Packages in a dependency cycle, and packages that depend on one, move to new global virtual store directories once after this update. Those that run a build miss the side-effects cache once.

• pnpm install and pnpm rebuild now refresh privately hoisted .bin shims in node_modules/.pnpm/node_modules/.bin after a dependency build replaces a script target with a native executable #17402.

• The Node.js latest selector now chooses the newest stable release #17490.

• The standalone @pnpm/exe builds now embed Node.js 26.13.0.

Repeat installs and lockfiles

• pnpm install now resolves a local directory again after its package.json changes when an override or a package extension adds it to the dependencies of a registry package. pnpm install --frozen-lockfile fails on a lockfile that still records the old dependencies of such a directory #17486.

• With injectWorkspacePackages and per-project lockfiles, pnpm install now updates a project's lockfile when a local tarball that an injected workspace project depends on is replaced. The project's lockfile kept the old version and integrity before.

• pnpm install now detects a change to a local tarball or directory that only a pnpmfile readPackage hook depends on. A repeat install reported "Already up to date" and kept the old contents before pnpm/tasks#227.

• pnpm install now relinks a workspace: or link: dependency whose link was deleted from node_modules. It used to report "Already up to date" and leave the link missing #17485.

• Merging git branch lockfiles now keeps a workspace project whose directory is named __proto__. It was dropped from the merged lockfile before pnpm/tasks#59.

Adding and publishing packages

• pnpm add no longer rewrites a catalog entry set to the dist-tag that the dependency resolves through. For example, an entry beta stays beta after pnpm add foo@beta or pnpm add foo. Before, the entry was replaced with the version the tag pointed to pnpm/tasks#225.

• pnpm pack and `pnpm publish

pnpm 12.17.0 adds pnpm peers check --global, dependency-group selectors and wildcards in overrides, and runtime, package manager, Cargo, and Python updates in pnpm outdated and pnpm update. It also fixes files that other users could not read in Docker images, and repeat installs that missed changes to local dependencies.

Minor Changes

• pnpm peers check now accepts --global (-g) to check globally installed packages. After a global install or update, the peer dependency warning now suggests pnpm peers check -g #17504.

• pnpm outdated and pnpm update now inspect and update package manager and runtime versions in devEngines.packageManager, packageManager, devEngines.runtime, engines.runtime, and runtime: dependencies. With cargo.enabled or python.enabled, pnpm outdated and pnpm update also inspect and update Cargo dependencies in Cargo.toml and Cargo.lock and Python dependencies in pyproject.toml and pylock.toml.

• overrides selectors now support :prod, :optional, and :peer pseudo-selectors that target a single dependency group. They also support * wildcard patterns on parent and target package names. An override with a non-range value, such as npm: or file:, no longer adds a peer dependency to dependencies. Removing an optional dependency with "-" now also removes the duplicate entry from dependencies #5391.

Patch Changes

Installing packages

• Files that pnpm creates in a project now get the permissions the umask gives any new file, such as 0644. Before, several of them were readable only by the user who ran pnpm, which broke Docker images that run as a different user #17435.

  The fix applies to:

  • node_modules/.pnpm-workspace-state-v1.json. A different user running pnpm run reinstalled the dependencies because it could not read this file.
  • pnpm-workspace.yaml
  • the files written by pnpm deploy
  • patch files from pnpm patch-commit
  • the lockfile restored by pnpm dedupe --check
  • the Cargo and Python files that pnpm writes

  When pnpm edits an existing file, the file keeps its permissions.

• pnpm install no longer writes broken dependency links when the project's node_modules is a symlink to another directory, such as another project's node_modules. The install reported success, but the links it wrote did not resolve #17448.

• Commands installed with pnpm add --global now find the dependencies that pnpm hoists for their package. A package that loads a dependency it does not declare, such as a native addon's platform-specific package, failed with "Cannot find module". Reinstall such a package with pnpm add --global to update its existing command #17503.

• When pnpm switches to the version a project pins, it now installs that version's native binary for the current host, even if the project's supportedArchitectures excludes the host. Before, pnpm could not use the pinned version and kept running the installed one. pnpm also repairs a pinned version that an earlier install left without the host's binary.

• With the global virtual store, a change to a dependency of one package in a dependency cycle now gives every package in that cycle a new directory. Before, the other packages kept their directories and still linked the old copy of the changed package, so the project could load two copies of it #17466.

  Packages in a dependency cycle, and packages that depend on one, move to new global virtual store directories once after this update. Those that run a build miss the side-effects cache once.

• With nodeLinker: hoisted, when two workspace projects need the same package version and it cannot be