# pnpm Store on Mac: Is It Safe to Delete?

> pnpm keeps one shared store of package files in ~/Library/pnpm/store. You can delete it, but pnpm store prune frees space without breaking anything.

- Updated: 2026-10-10
- URL: https://fresh.ist/caches/pnpm/

**TL;DR:** Deleting ~/Library/pnpm/store won't break your code, but it is rarely the best move. Every project installed with pnpm links its node_modules to files in that store, so pnpm has to download everything again on the next install. pnpm store prune removes only packages no project references and is the documented way to reclaim space.

## Facts from the Freshist app

- Category in Clean: pnpm Store — "Shared package store — projects re-download dependencies on next install."
- Location: `~/Library/pnpm/store`
- Risk level: Medium risk — Safe 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
- What Freshist does: Moves the selected items to the Trash, so you can undo. Nothing is deleted outright.

## 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

```bash
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:

```bash
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](/caches/npm/).

## Sources

- [pnpm: pnpm store](https://pnpm.io/cli/store)
- [pnpm: store settings (storeDir)](https://pnpm.io/settings/store)
- [pnpm: node-modules settings (packageImportMethod)](https://pnpm.io/settings/node-modules)

## 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.

---

Canonical page: https://fresh.ist/caches/pnpm/
Official site: https://fresh.ist/ (fresh.ist only)
Generated: 2026-10-10