The npm cache is 3 GB on this Mac, and nothing will ever clear it
npm's own manual says the cache only grows. Here is what is actually inside it on a real Mac, and the command that reclaims most of it without a slow reinstall.
You have deleted node_modules from the projects you finished last year, emptied the Trash, and the disk is still full. There is a second copy of every package you have ever installed, in one folder, and no version of npm has ever removed a byte of it.
du -sh ~/.npm/_cacacheOn the Mac this guide was written on, that answers 3.0 GB. Broken down, it looks like this, and the middle row is the surprise.
Inside _cacache | Size here | What it holds |
|---|---|---|
content-v2 | 2.5 GB | The package tarballs themselves, 4,034 files |
tmp | 487 MB | 47 leftovers from installs that were interrupted or failed |
index-v5 | 15 MB | The lookup index that maps a package to its content |
Nearly half a gigabyte of that is not cache at all. It is debris from installs that were cancelled with Control C, ran out of network, or hit a dependency error, and npm never went back for it.
npm's manual says this outright
This is not a bug and it is not a misconfiguration. Run npm help cache and the design is stated plainly: npm will not remove data by itself, and the cache grows as new packages are installed. There is no size cap, no age limit, and nothing that rotates it.
The age spread on this machine shows what that means over time. Of the 4,034 stored files, 15 are from ten months ago, 3,778 arrived in a single month of heavy work, and the rest are from the past few weeks. None of them are ever reconsidered.
Use verify, not clean
Every other page on this subject tells you to run npm cache clean --force. That works, and it is heavier than the job needs. npm cache verify does three things instead: it garbage collects any stored content that no index entry points at any more, it deletes the tmp directory outright, and it checks the integrity of what is left.
npm cache verifyIn other words it reclaims the 487 MB of debris and every tarball that is no longer referenced, and keeps the packages you are actually likely to install again. It prints what it reclaimed, so you can see the number rather than trust it.
| Command | What it removes | What the next install costs |
|---|---|---|
npm cache verify | All of tmp, plus content nothing references | Nothing for what it kept |
npm cache clean --force | Everything, back to an empty cache | One slow install while it refetches |
Both are safe. npm treats the cache as strictly a cache: if data is missing or corrupt it refetches, which is exactly why clean demands --force before it will run at all.
Every other package manager keeps its own
The npm cache is rarely alone. Each tool has a separate store in a separate place, and none of them prune on a schedule either.
du -sh ~/.npm/_cacache \
~/Library/pnpm/store \
~/.yarn/berry/cache \
~/.bun/install/cache \
~/.deno 2>/dev/null | sort -rhThe same Mac holds 521 MB in the pnpm store on top of the 3.0 GB in npm, for the same packages, because a project that switched package manager leaves both behind.
The pnpm store is the one exception
Do not delete the pnpm store with rm -rf. pnpm does not copy packages into a project, it links them from the store, so the files in a project's node_modules and the files in the store are the same files on disk. Removing the store folder frees far less than its size suggested, because the projects still holding links keep those files alive.
pnpm store pruneThat removes only what no project references any more, which is the operation you actually wanted. The same caution does not apply to npm: its cache is a plain copy and nothing links into it.
What this is worth in total
Package caches are the least visible part of a developer's disk because none of them are in a project folder, so cleaning up old work never touches them. On this machine the caches above came to roughly 3.5 GB with no project involved, and that is before the node_modules folders themselves, which are usually the larger number.
If you are working through a disk that is genuinely full rather than just untidy, the safest order to free 100 GB starts with the categories that are bigger than this one.
Common questions
Where is the npm cache on a Mac?
At ~/.npm/_cacache by default. Confirm it on your machine with npm config get cache, which prints the parent folder, since it can be moved with a config setting or an environment variable.
Is it safe to delete the npm cache?
Yes. npm treats it strictly as a cache and refetches anything missing, which is why the documentation says clearing it should never be necessary for any reason other than reclaiming disk space. The only cost is a slower next install.
What is the difference between npm cache clean and npm cache verify?
clean --force empties the cache completely. verify garbage collects only the content that nothing references any more, deletes the tmp folder of failed downloads, and checks the integrity of the rest. verify usually reclaims most of the space and costs nothing on the next install.
Why is the tmp folder inside _cacache so large?
It collects partial downloads from installs that were interrupted or failed, and npm does not clean it up on its own. It was 487 MB across 47 entries on the Mac used for this guide. npm cache verify removes the folder entirely.