# Pnpm

**pnpm** (performant npm) is an open-source package manager for [JavaScript](https://www.edgepedia.org/javascript) and Node.js projects that installs dependencies from a single content-addressable store on disk and links them into each project's `node_modules` with hard links and symbolic links, rather than copying every package into every project<sup>[1](https://github.com/pnpm/pnpm)</sup>. It resolves packages from the npm registry, records them in a lockfile called `pnpm-lock.yaml`, and enforces strict dependency access, so a package can only reach dependencies declared in its own `package.json`<sup>[1](https://github.com/pnpm/pnpm)</sup>. First released in 2016, it is used in production by teams of all sizes and is distributed under the MIT license, except its experimental Rust port `pacquet`, which is source-available under the PolyForm Shield License 1.0.0<sup>[1](https://github.com/pnpm/pnpm)</sup>.

| Key fact | Detail |
|---|---|
| What it is | A fast, disk-space-efficient JavaScript package manager with a lockfile (`pnpm-lock.yaml`), workspace support, and strict dependency access<sup>[1](https://github.com/pnpm/pnpm)</sup> |
| Storage model | All files from all projects live in one content-addressable store; `node_modules` files are hard links or reflinks (copy-on-write) into that store<sup>[1](https://github.com/pnpm/pnpm)</sup> |
| Current release | pnpm 12, a native executable that runs without Node.js; installing it through npm requires Node.js 22.13 or newer<sup>[2](https://github.com/pnpm/pnpm/blob/main/pnpm/docs/installation.md)</sup> |
| Security defaults (v11) | `minimumReleaseAge` defaults to 1440 minutes (1 day) and `blockExoticSubdeps` to `true`; build scripts require explicit approval via `allowBuilds`<sup>[3](https://github.com/pnpm/pnpm.io/blob/main/blog/releases/11.0.md)</sup> |
| Official benchmark | Clean install of the alotta-files project: npm 12.2.0 at 44.0 s versus pnpm 12.10.1 at 4.29 s, a 10.3x difference over an emulated 50 ms, 200 Mbps link<sup>[4](https://unixgaming.org/pnpm-vs-npm-vs-yarn-2026/)</sup> |
| Independent result | In one nine-workspace monorepo test, a cold CI-cache install took npm 12.9 s versus pnpm 39.8 s, while pnpm's `node_modules` used 7.9 MB of disk against npm's 384.8 MB<sup>[5](https://teachmeidea.com/pnpm-vs-npm-vs-yarn-install-times/)</sup> |
| License | MIT, except the `pacquet/` Rust port directory (PolyForm Shield 1.0.0)<sup>[1](https://github.com/pnpm/pnpm)</sup> |

## How it stores packages

pnpm keeps every file from every installed package in a single content-addressable store on the machine. When 100 projects depend on the same package, npm leaves 100 copies on disk; with pnpm the package is stored once and linked into each project. If a new version of a package changes only one file out of 100, an update adds only that one file to the store. Linking uses hard links, or reflinks (copy-on-write) where the filesystem supports them, so linked files consume no additional disk space<sup>[1](https://github.com/pnpm/pnpm)</sup>.

The store index changed with version 11: instead of one JSON file per package under the store, pnpm 11 keeps a single SQLite database at `$STORE/index.db`, using [MessagePack](https://www.edgepedia.org/messagepack) values and WAL mode for concurrent access, with package manifests bundled into the index so resolution needs fewer reads<sup>[3](https://github.com/pnpm/pnpm.io/blob/main/blog/releases/11.0.md)</sup>.

## The symlinked node_modules layout

pnpm builds a nested `node_modules` structure with symbolic links. Every file of every package inside `node_modules` is first hard-linked from the store into a hidden virtual store at `node_modules/.pnpm`, organized as folders named like `foo@1.0.0`. Symbolic links then assemble the dependency graph: a package's dependencies are symlinked into that package's own `node_modules` folder, and the project's direct dependencies are symlinked from the root `node_modules`<sup>[6](https://github.com/pnpm/pnpm.io/blob/main/docs/symlinked-node-modules-structure.md)</sup>.

This layout stays compatible with Node.js module resolution because Node ignores symlinks when resolving modules and resolves to the real path, so a package always finds its own dependencies beside it, however deep the dependency graph is<sup>[6](https://github.com/pnpm/pnpm.io/blob/main/docs/symlinked-node-modules-structure.md)</sup>. The practical consequence is strictness: only packages actually listed as dependencies are reachable, whereas a flattened `node_modules` exposes every hoisted package to every file. Because many packages in the ecosystem use undeclared dependencies, pnpm hoists all dependencies by default into `node_modules/.pnpm/node_modules`; setting `hoist` to `false` disables this<sup>[6](https://github.com/pnpm/pnpm.io/blob/main/docs/symlinked-node-modules-structure.md)</sup>.

## Version history

pnpm was created by Ricardo N. Gomes da Silva (rstacruz) and Zoltan Kochan; early issues on the repository date from January 2016, and the README describes it as used in production since 2016<sup>[1](https://github.com/pnpm/pnpm)</sup>. Kochan has remained the maintainer signing the project's releases<sup>[7](https://github.com/pnpm/pnpm/releases)</sup>.

**pnpm 11**, released 28 April 2026, required Node.js 22 or newer, made pnpm itself pure ESM, and flipped several defaults toward supply-chain safety: newly published packages are not resolved until at least one day old (`minimumReleaseAge: 1440`), and exotic subdependencies are blocked by default. It replaced the legacy build-script settings with a single `allowBuilds` map, isolated global installs so each `pnpm add -g` gets its own directory with its own lockfile, and reimplemented `publish`, `login`, `view`, `deprecate`, and related registry commands natively instead of delegating to the npm CLI<sup>[3](https://github.com/pnpm/pnpm.io/blob/main/blog/releases/11.0.md)</sup>.

**pnpm 12** is the current release line. It is a native executable that does not require Node.js after installation, with prebuilt binaries for Linux (glibc and musl), macOS, Windows, FreeBSD, and Android across x64, arm64, and additional architectures; FreeBSD, ppc64le, s390x, RISC-V, and Android targets were added in v12.4.0<sup>[2](https://github.com/pnpm/pnpm/blob/main/pnpm/docs/installation.md)</sup>. The install engine behind pnpm 12 is the Rust port the project calls pacquet<sup>[8](https://systhoughts.com/posts/npm-vs-pnpm-supply-chain-pnpm-12)</sup>. Recent releases in the 12.x line have added OIDC authentication for `pnpm dist-tag` in CI, a `tool:` protocol for installing Node.js, Bun, Deno, and Yarn runtimes through pnpm, and repeated security fixes, including two credential-leak paths fixed in pnpm 11.28.4<sup>[7](https://github.com/pnpm/pnpm/releases)</sup>.

## Performance

pnpm publishes a live benchmark page comparing npm, pnpm, Yarn Classic, and Yarn PnP across scenarios such as clean install, cache-only install, and lockfile install on a CI server<sup>[9](https://www.pnpm.cn/uk/benchmarks)</sup>. Data fetched from that suite in October 2026, run over an emulated 50 ms, 200 Mbps network link on the many-small-packages project alotta-files, gave these fastest runs<sup>[4](https://unixgaming.org/pnpm-vs-npm-vs-yarn-2026/)</sup>:

| Scenario | npm 12.2.0 | pnpm 12.10.1 | Speedup |
|---|---|---|---|
| Clean install | 44.0 s | 4.29 s | 10.3x |
| Lockfile install (CI, first run) | 10.6 s | 3.30 s | 3.2x |
| Cache reinstall (no lockfile) | 8.33 s | 945 ms | 8.8x |
| Cache + lockfile reinstall | 5.16 s | 797 ms | 6.5x |

Independent benchmarks broadly agree that pnpm is faster than npm but rank the tools differently in detail. A 2026 cross-comparison of a 50-dependency project measured a cold install at 14.3 s on npm, 6.8 s on Yarn, and 4.2 s on pnpm, and a warm install (cache plus lockfile) at 5.1 s on npm, 1.2 s on Yarn, and 1.8 s on pnpm, putting Yarn slightly ahead when the cache is warm<sup>[10](https://tech-insider.org/pnpm-vs-yarn-2026/)</sup>. On a Next.js project with 847 dependencies, PkgPulse measured clean installs of 28.4 s (npm), 14.3 s (Yarn v4 PnP), and 15.7 s (pnpm), and cached installs of 12.1 s, 3.2 s, and 5.8 s respectively<sup>[11](https://www.pkgpulse.com/guides/npm-vs-yarn-vs-pnpm-2026)</sup>. In a [Turborepo](https://www.edgepedia.org/turborepo) monorepo benchmark with 15 packages and about 3,500 total dependencies, npm took 134.2 s, Yarn 52.3 s, and pnpm 28.6 s<sup>[12](https://devtoolswatch.com/en/pnpm-vs-npm-vs-yarn-2026)</sup>.

The size of the advantage depends on cache state. In the TeachMeIDEA monorepo test, npm finished a cold CI-cache install in 12.9 s while pnpm needed 39.8 s, so pnpm's speed advantage depends on a warm store; the same test found pnpm's `node_modules` occupied 7.9 MB of actual disk against npm's 384.8 MB<sup>[5](https://teachmeidea.com/pnpm-vs-npm-vs-yarn-install-times/)</sup>. Disk efficiency is the most consistent result across tests: because files are linked from one store, repeated projects share storage instead of duplicating it<sup>[1](https://github.com/pnpm/pnpm)</sup>.

## Supply-chain security

pnpm's security model centers on controlling what runs and where dependencies come from. Dependency build scripts require explicit approval, and the `minimumReleaseAge` setting delays resolution of newly published packages so that freshly published malicious versions have time to be detected; if a dependency did not require a build in the past, a compromised later version will not suddenly run a script. pnpm also resolves all transitive dependencies from trusted sources and supports a `trustPolicy` setting<sup>[13](https://github.com/pnpm/pnpm.io/blob/main/docs/supply-chain-security.md)</sup>. Version 11.4 made tarball-integrity mismatches a hard install failure by default, and later releases added verification of locked config dependencies against the registry and signature checks tied to lockfile integrity<sup>[7](https://github.com/pnpm/pnpm/releases)</sup>.

Adoption has grown alongside these features: pnpm's CLI recorded 8.1 million weekly downloads in a March 2026 comparison, up threefold since 2024, against 5.2 million for Yarn<sup>[11](https://www.pkgpulse.com/guides/npm-vs-yarn-vs-pnpm-2026)</sup>.

## References

1. [pnpm/pnpm: Fast, disk space efficient package manager, GitHub](https://github.com/pnpm/pnpm)
2. [pnpm/pnpm docs/installation.md, GitHub](https://github.com/pnpm/pnpm/blob/main/pnpm/docs/installation.md)
3. [pnpm 11.0 release notes, pnpm.io blog](https://github.com/pnpm/pnpm.io/blob/main/blog/releases/11.0.md)
4. [pnpm vs npm vs Yarn 2026 install benchmarks, unixgaming.org](https://unixgaming.org/pnpm-vs-npm-vs-yarn-2026/)
5. [pnpm vs npm vs Yarn: Install Times in a Real Monorepo, Measured, TeachMeIDEA](https://teachmeidea.com/pnpm-vs-npm-vs-yarn-install-times/)
6. [Symlinked node_modules structure, pnpm docs](https://github.com/pnpm/pnpm.io/blob/main/docs/symlinked-node-modules-structure.md)
7. [Releases, pnpm/pnpm, GitHub](https://github.com/pnpm/pnpm/releases)
8. [npm vs pnpm in 2026: Speed, Workspaces, and the Supply Chain Case, systhoughts](https://systhoughts.com/posts/npm-vs-pnpm-supply-chain-pnpm-12)
9. [Benchmarks of JavaScript Package Managers, pnpm](https://www.pnpm.cn/uk/benchmarks)
10. [pnpm vs Yarn 2026, tech-insider.org](https://tech-insider.org/pnpm-vs-yarn-2026/)
11. [npm vs Yarn vs pnpm (2026), PkgPulse Guides](https://www.pkgpulse.com/guides/npm-vs-yarn-vs-pnpm-2026)
12. [pnpm vs npm vs Yarn 2026: Complete Comparison, DevTools Research](https://devtoolswatch.com/en/pnpm-vs-npm-vs-yarn-2026)
13. [Supply-chain security, pnpm docs](https://github.com/pnpm/pnpm.io/blob/main/docs/supply-chain-security.md)

---
*Topic: Encyclopedia › Technology and the built world › Computing and digital systems › Software and programming › Development tools and collaboration infrastructure › Build, deployment, and development tooling*

*Initially written Sep 17, 2026 · Reviewed: Sep 30, 2026; Oct 15, 2026 · Edited: Sep 30, 2026; Oct 11, 2026; Oct 15, 2026 · Last review: Oct 15, 2026*

*Copyright 2026 EdgeChat AI, a subsidiary of Biostate AI.*

License: Edgepedia Community License 1.0, https://www.edgepedia.org/edgepedia/license