Deleting project level dependency folders is the visible half of the job. The invisible half is the global store each package manager maintains in your home directory, holding every tarball it has ever downloaded. These caches are shared across projects, so they are not redundant, but they also never shrink on their own.
Where the caches live on macOS
- npm:
~/.npm/_cacache - yarn (classic):
~/Library/Caches/Yarn - yarn (berry):
~/.yarn/berry/cache - pnpm:
~/Library/pnpm/store - Bun:
~/.bun/install/cache
Measure them together before deciding anything:
du -sh ~/.npm/_cacache ~/Library/Caches/Yarn ~/.yarn/berry/cache ~/Library/pnpm/store ~/.bun/install/cache 2>/dev/nullA few gigabytes is normal. Anything past 10GB means years of accumulated tarballs, including every prerelease and every package you tried once.
Clearing each one properly
Use the package manager's own command rather than deleting folders, because it also maintains the index that points at the files:
npm cache clean --force
yarn cache clean
pnpm store prune
bun pm cache rmEach of these is safe. The next install re-downloads what it needs, so the first npm install after clearing is slower and the ones after that are normal again.
The version manager caches people miss
If you use nvm or fnm to switch Node versions, every version you have ever installed is still on disk under ~/.nvm/versions/node. Old versions that no project requires today can be removed:
nvm ls
nvm uninstall 16.20.2Homebrew has a matching pair of commands for its download cache and old versions:
brew cleanup --prune=allmacoptimize groups npm, yarn, pnpm, Homebrew and version manager caches into one Package managers category in the Clean tab, with the size of each store shown before you select it. It also keeps the sizes in the History tab, so you can see whether a cache is drifting back up.
Should you clear these at all?
It depends on your connection and how often you rebuild projects from scratch.
- Clear them if disk space is tight, you are on a fast connection, and your installs are usually from a lockfile.
- Keep them if you work offline, if you regularly install the same large dependency sets, or if your team uses a private registry that is slow over VPN.
A middle course works well: run pnpm store prune or npm cache clean --force once a quarter, and keep an eye on the total rather than clearing on a schedule.
What each command actually removes
The cache commands look interchangeable and are not. This is what each one really does:
| Command | Removes | Keeps |
|---|---|---|
| npm cache verify | Corrupt or partial entries | Everything else |
| npm cache clean --force | Every tarball in the cache | Nothing |
| yarn cache clean | The shared Yarn cache | node_modules in projects |
| pnpm store prune | Versions no project references | Everything in use |
| brew cleanup --prune=all | Old versions and downloads | The current version of each formula |
npm cache verify is the one to run monthly. It checks the integrity of every entry and deletes only what fails, which is a genuinely useful maintenance step rather than a blank reset.
pnpm store prune is the most considerate of the five, since it works out which package versions nothing on the machine points at and removes exactly those. There is no equivalent for npm, which is why the npm cache keeps growing on machines with many projects.
The stores that scale with your project count
A cache for one project is small. The same cache across four years of projects is not, because every version of every package ever installed is still sitting in it. Two numbers explain most of what people find:
- A developer running npm across 50 projects accumulates 2GB to 8GB in
~/.npm/_cacache. - The pnpm store deduplicates across projects, so 50 projects might sit at 1GB to 4GB, since ten projects using the same React version share one copy.
Neither is a problem to fix by default. Both are worth knowing about when you are hunting for the last few gigabytes.
Check the real size of each store before deciding anything:
du -sh ~/.npm ~/.yarn ~/Library/Caches/Yarn ~/Library/pnpm ~/.cache 2>/dev/null | sort -hrmacoptimize lists these under the Developer group with their exact sizes and the path each one lives at, so you can clear one store without touching the others.
Rebuilding after a full clear
Clearing a cache does not delete installed projects, so nothing breaks immediately. The cost appears at the next install, and it is mostly about network:
- Expect the next install in each project to be two to five times slower.
- Expect it to download the same packages you just deleted, which on a metered connection is real data.
- If you work offline or on a plane, do not clear caches before a long flight.
pnpm store prune avoids this entirely for the packages still in use, which is why it is the command worth running by default and the others are worth running occasionally.
Other ecosystems with the same habit
The pattern is not specific to JavaScript. CocoaPods keeps a specs repo and download cache under ~/.cocoapods, Homebrew downloads installers into ~/Library/Caches/Homebrew, Gradle keeps dependency jars in ~/.gradle/caches, and Swift Package Manager keeps checkouts per project. Every one of them regenerates on demand, and every one of them grows quietly for years.
FAQ
Does npm cache clean --force break existing projects?
No. It empties the download cache, which only affects future installs. Projects with node_modules already installed keep working, and installed packages are never stored in the cache in a form the project depends on.
Why does yarn use a different path than npm?
Different tools made different choices. npm keeps everything under ~/.npm, Yarn 1.x historically used ~/Library/Caches/Yarn on macOS, and pnpm stores hard linked packages in ~/Library/pnpm. That is why one size check across all three is worth running before you assume where the space is.
How big should these caches be?
There is no correct size, only a relationship to how much you install. A few hundred megabytes is typical for one or two projects, and several gigabytes is normal after years of work across many repos. Treat anything over 5GB as worth a look rather than an emergency.
Will clearing caches make my installs slower?
Yes, temporarily. The next install in each project has to download packages again, so expect it to be two to five times slower, and to use real bandwidth. For pnpm, store prune avoids this for every package still referenced by a project.
Is it safe to clear the caches while a build is running?
Wait until it finishes. A running install reads from the cache, and clearing entries underneath it can surface as checksum errors that look like a broken package. It is a rare failure but an annoying one to diagnose.