Information Density: pnpm – Signal Evidence & AI Readability

[H1] pnpm: Save time. Save disk space. Supercharge your monorepos.
Get lightning-fast installation speeds and a smarter, safer way to manage dependencies.Getting startedStar33.4K
[H3] Fast
pnpm is optimized for installation speed. We believe waiting for dependencies to install is a waste of time. Your time is valuable, and so is ours.
[IMG: Illustration of pnpm Fast feature.]
[H3] Saving Disk Space
[H3] Workspace Support
[H3] Managing Runtimes
[IMG: Illustration of pnpm Fast feature.]
[H2] These are the sponsors
PLATINUM SPONSORS
[IMG: Bit]
Bit CloudGOLD SPONSORS
[IMG: Sanity]
Sanity
[IMG: Discord]
Discord
[IMG: Vite]
Vitejs
[IMG: SerpApi]
SerpApi
[IMG: CodeRabbit]
Code Rabbit
[IMG: Stackblitz]
StackBlitz
[IMG: Workleap]
Workleap
[IMG: Nx]
NxSILVER SPONSORS
[IMG: Replit]
Replit
[IMG: Cybozu]
Cybozu
[IMG: devowl.io]
Devowlio
[IMG: u|screen]
Uscreen
[IMG: Leniolabs_]
LeniolabsDepotCerbos⏱️Time.now@pnpmjs is a strong option for protecting against supply chain attacks, and the DX is excellent too they removed postinstall scripts a while back, cutting one big attack path now they’ve introduced minimumReleaseAge which lets you hold off on new versions for a day or more
[IMG: Feross]
[H6] Feross
@ferossIts not even been a day but I suddenly feel that @pnpmjs has improved my overall dev experience ?
[IMG: Sayantan Ghosh]
[H6] Sayantan Ghosh
@sayantan__ghoshThis whole time I've stuck with npm out of habit and because it "just works". But then I had to override a subdependency via package.json, and npm just wouldn't do it. I spent hours fiddling. So @darcy recommends I use @pnpmjs , and w/ the same package.json, it "just works".
[IMG: Ben Vinegar]
[H6] Ben Vinegar
@bentlegenGotta say @pnpmjs has never let me down. Great piece of software.
[IMG: Guillermo Rauch]
[H6] Guillermo Rauch
@rauchgBy adopting the latest changes from @pnpmjs we got huge performance benefits in @bitdev_ ! still early to call true numbers, but i'm seeing decreases of 40% in some flows! incredible work by @ZoltanKochan and the team behind pnpm!
[IMG: Itay Mendelawy]
[H6] Itay Mendelawy
@itaymendelI ❤️ pnpm. Just radically sped up a CI build by switching to pnpm and parallelizing tasks (which pnpm supports built-in) Before: 12 minutes After: 2 minutes ?
[IMG: Cory House]
[H6] Cory House
@housecor
[H2] OSS projects that use pnpm
next.jsn8n
[IMG: Material UI]
Material UI
[IMG: Vite]
Vite
[IMG: Nuxt]
Nuxt
[IMG: Vue]
VueAstroPrismaNovu
[IMG: Slidev]
Slidev
[IMG: Turborepo]
Turborepo
[IMG: Quasar Framework]
Quasar Framework
[IMG: Element Plus]
Element Plus
[IMG: NextAuth.js]
NextAuth.js
[IMG: Ember.js]
Ember.js
[IMG: Qwik]
Qwik
[IMG: VueUse]
VueUse
[IMG: SvelteKit]
SvelteKit
[IMG: Verdaccio]
VerdaccioVercel
[IMG: Nx]
Nx

Version: 11.xOn this page
[H2] Saving disk space​
[IMG: An illustration of the pnpm content-addressable store. On the illustration there are two projects with node_modules. The files in the node_modules directories are hard links to the same files in the content-addressable store.]
When using npm, if you have 100 projects using a dependency, you will
have 100 copies of that dependency saved on disk. With pnpm, the dependency will be
stored in a content-addressable store, so:
If you depend on different versions of the dependency, only the files that
differ are added to the store. For instance, if it has 100 files, and a new
version has a change in only one of those files, pnpm update will only add 1
new file to the store, instead of cloning the entire dependency just for the
singular change.
All the files are saved in a single place on the disk. When packages are
installed, their files are hard-linked from that single place, consuming no
additional disk space. This allows you to share dependencies of the same version
across projects.
As a result, you save a lot of space on your disk proportional to the number of
projects and dependencies, and you have a lot faster installations!
[H2] Boosting installation speed​
pnpm performs installation in three stages:
Dependency resolution. All required dependencies are identified and fetched to the store.
Directory structure calculation. The node_modules directory structure is calculated based on the dependencies.
Linking dependencies. All remaining dependencies are fetched and hard linked from the store to node_modules.
[IMG: An illustration of the pnpm install process. Packages are resolved, fetched, and hard linked as soon as possible.]
This approach is significantly faster than the traditional three-stage installation process of resolving, fetching, and writing all dependencies to node_modules.
[IMG: An illustration of how package managers like Yarn Classic or npm install dependencies.]
[H2] Creating a non-flat node_modules directory​
When installing dependencies with npm or Yarn Classic, all packages are hoisted to the root of the
modules directory. As a result, source code has access to dependencies that are
not added as dependencies to the project.
By default, pnpm uses symlinks to add only the direct dependencies of the project into the root of the modules directory.
[IMG: An illustration of a node_modules directory created by pnpm. Packages in the root node_modules are symlinks to directories inside the node_modules/.pnpm directory]
If you'd like more details about the unique node_modules structure that pnpm
creates and why it works fine with the Node.js ecosystem, read:
Flat node_modules is not the only way
Symlinked node_modules structure
tipIf your tooling doesn't work well with symlinks, you may still use pnpm and set the nodeLinker setting to hoisted. This will instruct pnpm to create a node_modules directory that is similar to those created by npm and Yarn Classic.Saving disk spaceBoosting installation speedCreating a non-flat node_modules directory

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 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.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 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.pnpm 10.32 adds an --all flag to pnpm approve-builds for approving all pending builds without interactive prompts.pnpm 10.31 preserves comments and formatting when updating pnpm-workspace.yaml, and includes numerous bug fixes.pnpm 10.30 redesigns pnpm why to show a reverse dependency tree, making it much easier to understand why a package is installed.pnpm 10.29 adds catalog: protocol support to pnpm dlx, allows configuring auditLevel in pnpm-workspace.yaml, supports a bare workspace: specifier, and includes several bug fixes.pnpm 10.28 introduces a new beforePacking hook to customize package.json at publish time, improves filtered install performance, and includes several bug fixes.pnpm 10.27 adds a new setting to ignore trust policy checks for older package versions, introduces a project registry for global virtual store pruning, and includes several bug fixes.

Version: 11.xOn this page
[H2] Why does my node_modules folder use disk space if packages are stored in a global store?​
pnpm creates hard links from the global store to the project's node_modules
folders. Hard links point to the same place on the disk where the original
files are. So, for example, if you have foo in your project as a dependency
and it occupies 1MB of space, then it will look like it occupies 1MB of space in
the project's node_modules folder and the same amount of space in the global
store. However, that 1MB is the same space on the disk addressed from two
different locations. So in total foo occupies 1MB, not 2MB.
For more on this subject:
Why do hard links seem to take the same space as the originals?
A thread from the pnpm chat room
An issue in the pnpm repo
[H2] Does it work on Windows?​
Short answer: Yes.
Long answer: Using symbolic linking on Windows can sometimes be problematic,
however, pnpm has a workaround. For Windows, if the Developer Mode is off, we use junctions instead.
[H2] But the nested node_modules approach is incompatible with Windows?​
Early versions of npm had issues because of nesting all node_modules (see
this issue). However, pnpm does not create deep folders, it stores all packages
flatly and uses symbolic links to create the dependency tree structure.
[H2] What about circular symlinks?​
Although pnpm uses linking to put dependencies into node_modules folders,
circular symlinks are avoided because parent packages are placed into the same
node_modules folder in which their dependencies are. So foo's dependencies
are not in foo/node_modules, but foo is in node_modules together with its
own dependencies.
[H2] Why have hard links at all? Why not symlink directly to the global store?​
One package can have different sets of dependencies on one machine.
In project A foo@1.0.0 can have a dependency resolved to bar@1.0.0, but
in project B the same dependency of foo might resolve to bar@1.1.0; so,
pnpm hard links foo@1.0.0 to every project where it is used, in order to
create different sets of dependencies for it.
Direct symlinking to the global store would work with Node's
--preserve-symlinks flag, however, that approach comes with a plethora of its
own issues, so we decided to stick with hard links. For more details about why
this decision was made, see this issue.
[H2] Does pnpm work across different subvolumes in one Btrfs partition?​
While Btrfs does not allow cross-device hardlinks between different subvolumes in a single partition, it does permit reflinks. As a result, pnpm utilizes reflinks to share data between these subvolumes.
[H2] Does pnpm work across multiple drives or filesystems?​
The package store should be on the same drive and filesystem as installations,
otherwise packages will be copied, not linked. This is due to a limitation in
how hard linking works, in that a file on one filesystem cannot address a
location in another. See Issue #712 for more details.
pnpm functions differently in the 2 cases below:
[H3] Store path is specified​
If the store path is specified via the store config, then copying
occurs between the store and any projects that are on a different disk.
If you run pnpm install on disk A, then the pnpm store must be on disk A.
If the pnpm store is located on disk B, then all required packages will be
directly copied to the project location instead of being linked. This severely
inhibits the storage and performance benefits of pnpm.
[H3] Store path is NOT specified​
If the store path is not set, then multiple stores are created (one per drive or
filesystem).
If installation is run on disk A, the store will be created on A
.pnpm-store under the filesystem root. If later the installation is run on
disk B, an independent store will be created on B at .pnpm-store. The
projects would still maintain the benefits of pnpm, but each drive may have
redundant packages.
[H2] What does pnpm stand for?​
pnpm stands for performant npm.
@rstacruz came up with the name.
[H2] pnpm does not work with <YOUR-PROJECT-HERE>?​
In most cases it means that one of the dependencies require packages not
declared in package.json. It is a common mistake caused by flat
node_modules. If this happens, this is an error in the dependency and the
dependency should be fixed. That might take time though, so pnpm supports
workarounds to make the buggy packages work.
[H3] Solution 1​
In case there are issues, you can use the nodeLinker: hoisted setting.
This creates a flat node_modules structure similar to the one created by npm.
[H3] Solution 2​
In the following example, a dependency does not have the iterall module in
its own list of deps.
The easiest solution to resolve missing dependencies of the buggy packages is to
add iterall as a dependency to our project's package.json.
You can do so, by installing it via pnpm add iterall, and will be
automatically added to your project's package.json.
"dependencies": { ... "iterall": "^1.2.2", ... }
[H3] Solution 3​
One of the solutions is to use hooks for adding the missing
dependencies to the package's package.json.
An example was Webpack Dashboard which wasn't working with pnpm. It has
since been resolved such that it works with pnpm now.
It used to throw an error:
Error: Cannot find module 'babel-traverse' at /node_modules/inspectpack@2.2.3/node_modules/inspectpack/lib/actions/parse
The problem was that babel-traverse was used in inspectpack which
was used by webpack-dashboard, but babel-traverse wasn't specified in
inspectpack's package.json. It still worked with npm and yarn because
they create flat node_modules.
The solution was to create a .pnpmfile.mjs with the following contents:
export const hooks = { readPackage: (pkg) => { if (pkg.name === "inspectpack") { pkg.dependencies['babel-traverse'] = '^6.26.0'; } return pkg; }}
After creating a .pnpmfile.mjs, delete pnpm-lock.yaml only - there is no need
to delete node_modules, as pnpm hooks only affect module resolution. Then,
rebuild the dependencies & it should be working.Why does my node_modules folder use disk space if packages are stored in a global store?Does it work on Windows?But the nested node_modules approach is incompatible with Windows?What about circular symlinks?Why have hard links at all? Why not symlink directly to the global store?Does pnpm work across different subvolumes in one Btrfs partition?Does pnpm work across multiple drives or filesystems?Store path is specifiedStore path is NOT specifiedWhat does pnpm stand for?pnpm does not work with <YOUR-PROJECT-HERE>?Solution 1Solution 2Solution 3