pnpm Store on Mac: Is It Safe to Delete?
Medium riskPackage managers & build toolsUpdated
- Location
~/Library/pnpm/store
- Risk level
- Medium riskSafe to remove, but the tool that owns it re-downloads or rebuilds it on next use, which costs time and bandwidth. Listed, never pre-selected.
- Selected by default
- No — you choose whether to include it
- What Freshist does
- Moves the selected items to the Trash, so you can undo. Nothing is deleted outright.
- In the app
- Clean → pnpm Store — “Shared package store — projects re-download dependencies on next install.”
From Freshist's own cleaning rules — the same catalog the app uses.
How the pnpm store works
pnpm doesn't copy every dependency into every project. It keeps a single content-addressable store on each disk, and each project's node_modules points into it. The pnpm docs list ~/Library/pnpm/store as the macOS default, unless PNPM_HOME or XDG_DATA_HOME is set, in which case the store moves to $PNPM_HOME/store or $XDG_DATA_HOME/pnpm/store.
Inside you'll find a versioned layout folder such as v10 or v11. It contains the package files, an index, and with newer pnpm versions folders such as links and projects used for the global virtual store.
Why it grows
Every version of every package you have ever installed with pnpm stays in the store until you prune it. Switching branches, upgrading dependencies, trying out a project once, or upgrading pnpm itself (which starts a new layout folder) all add to it. Nothing is removed automatically.
Linking on macOS, and what that means for space
The packageImportMethod setting defaults to auto, which on macOS tries clone first, then hard link, then copy. Clones on APFS share disk blocks with the store until a file changes. That has two practical effects:
| Situation | Space actually freed when the store is deleted |
|---|---|
| Projects using these packages still exist | Little; their node_modules still hold the shared blocks |
| Projects already deleted or their node_modules removed | Most of what du reports |
| Old layout folder from an earlier pnpm version | Usually all of it |
So du -sh on the store can overstate what you'd get back.
What breaks if you delete it
With the default settings, existing node_modules folders keep working, because their files are clones or hard links that keep the data alive. The exception is the optional global virtual store (enableGlobalVirtualStore): projects using it symlink into the store's links folder and need a fresh pnpm install after the store is gone. In every case, the next pnpm install in any project finds the store empty and downloads every dependency again. In a large monorepo that can take a while on a slow connection. Offline installs fail until the store is repopulated.
Read-only checks
pnpm store path # the active store, e.g. ~/Library/pnpm/store/v11
du -sh ~/Library/pnpm/store
ls ~/Library/pnpm/store
pnpm store status # checks for modified packages in the store
Clean it with pnpm
The documented command is:
pnpm store prune
It removes packages that no project on the system references. The pnpm docs say pruning has no side effects on projects, and that removed packages are downloaded again only if a later install needs them. They also suggest running it occasionally rather than constantly, because pruning right before you switch back to an older branch means refetching those packages.
Prune only works on the layout your current pnpm uses. Compare pnpm store path with ls ~/Library/pnpm/store: a layout folder that isn't the active one belongs to an earlier pnpm version, and moving it to the Trash is the usual way to drop that leftover after a major upgrade.
When the store is worth keeping
Keep the store if you're on a slow or metered connection, or if you work across many pnpm projects that share dependencies. Sharing one store across projects is what saves pnpm users space in the first place, so wiping it undoes that until every project reinstalls. npm keeps a simpler tarball cache, described in the npm cache guide.
Sources
Frequently asked questions
Why didn't deleting the pnpm store free as much space as expected?
On macOS, pnpm clones (APFS copy-on-write) or hard-links store files into each project's node_modules. While those projects exist, they still share the same disk blocks, so the space only comes back once their node_modules folders are gone too.
What is the v10 or v11 folder inside the store?
pnpm versions the store layout. When a pnpm upgrade changes the format, a new folder like v10 or v11 appears and the old one is no longer used by the new version. An old layout folder is a common leftover after upgrading pnpm.
Can I move the pnpm store to an external drive?
You can set storeDir, but pnpm expects the store on the same disk as your projects. On a different disk it copies packages instead of linking them, which costs more space and time.