If you write JavaScript or TypeScript on a Mac, your three package managers have quietly filled gigabytes of disk space with cached tarballs, metadata, and content-addressable blobs. Knowing how to clear npm cache, clean up Yarn, and prune pnpm — and understanding which caches are safe to wipe — saves real space without breaking your workflow. This guide covers all three side by side.
Where Each Cache Lives on macOS
Before running any command it helps to know what you are actually deleting. All three caches sit under your home directory and are independent of your project's node_modules folders.
| Package manager | Default cache path (macOS) | Typical size |
|---|---|---|
| npm | ~/.npm |
500 MB – 4 GB |
| Yarn Classic (v1) | ~/Library/Caches/Yarn/v6 |
1 – 6 GB |
| Yarn Berry (v2+) | ~/Library/Caches/yarn/berry (or project .yarn/cache) |
varies |
| pnpm | ~/.local/share/pnpm/store (or ~/Library/pnpm/store) |
1 – 10 GB |
To check your actual cache location before touching anything, each manager exposes a command for it:
# npm
npm config get cache
# Yarn Classic
yarn cache dir
# pnpm
pnpm store path
How to Clear npm Cache
npm's cache stores compressed tarballs and integrity metadata. The recommended way to clear it is through npm itself rather than deleting the directory by hand, because npm maintains a checksum index inside the cache folder.
- Open Terminal.
- Verify the cache size first so you know what you are about to remove:
du -sh ~/.npm - Run the clean command:
Thenpm cache clean --force--forceflag is required because npm intentionally resists manual cache manipulation to protect against accidental data loss. - Confirm the cache is gone:
npm cache verify
Is it safe? Yes. npm will re-download packages on the next install. You will not lose any installed packages; only the local copy of downloaded tarballs is removed. Cold installs in CI environments or on slow connections will take longer until the cache rebuilds.
How to Run yarn cache clean
Yarn Classic (v1) stores unpacked package directories in its cache. Yarn Berry (v2 and later) stores zip archives, either in a global cache or inside each project depending on your nodeLinker setting.
Yarn Classic (v1)
- Check the size:
du -sh "$(yarn cache dir)" - Clear the entire global cache:
yarn cache clean - To remove only a specific package's cached files:
yarn cache clean <package-name>
Yarn Berry (v2+)
- If your project uses
nodeLinker: node-modulesorpnp, the global cache lives at the path reported by:yarn config get globalFolder - Clear the global Yarn Berry cache:
yarn cache clean --all - If your project uses Zero-Installs (cache checked into the repo), do not delete
.yarn/cache— that would break offline installs for your whole team.
Is it safe? Yes for the global cache. Yarn re-fetches packages on the next install. Be careful with project-level caches in Zero-Install repos — those are intentionally committed.
How to Use pnpm store prune
pnpm uses a content-addressable store: every package version is stored once, and projects hard-link to it. This is why pnpm installs are fast and disk-efficient when you have multiple projects — but the store grows over time as you accumulate versions of packages you no longer use.
- Find out how large your store is:
du -sh "$(pnpm store path)" - Remove packages that are not referenced by any project on your machine:
This is the safe, surgical option. It only removes orphaned package versions.pnpm store prune - To wipe the entire store (every cached package regardless of references):
Only do this if you want to start completely fresh. All projects will download their full dependency trees on the next install.pnpm store path # note this path rm -rf "$(pnpm store path)"
Is it safe? pnpm store prune is safe and recommended as routine maintenance — pnpm itself suggests running it periodically. Deleting the entire store is permanent and will slow down your next install across every project, but nothing breaks; packages are simply re-fetched.
Quick-Reference Command Summary
| Manager | Recommended clean command | Scope | Safe to run? |
|---|---|---|---|
| npm | npm cache clean --force |
All cached tarballs | Yes |
| Yarn Classic | yarn cache clean |
All cached packages | Yes |
| Yarn Berry | yarn cache clean --all |
Global cache only | Yes (avoid project cache in Zero-Install repos) |
| pnpm | pnpm store prune |
Unreferenced packages only | Yes |
| pnpm | rm -rf $(pnpm store path) |
Entire store | Yes, but cold installs on next run |
A Note on node_modules
The package-manager caches described above are separate from the node_modules directories inside each project. Those are not caches — they are your installed dependencies. Deleting them is safe if you re-run your install command afterward, but they are not what bloats ~/Library/Caches or ~/.npm. If you want to find which projects' node_modules are taking space, run:
find ~ -name "node_modules" -type d -prune -maxdepth 6 2>/dev/null \
| xargs du -sh 2>/dev/null \
| sort -rh \
| head -20
That surfaces the largest node_modules trees so you can clean up old or abandoned projects.
Doing This Without Memorizing Every Command
If you work across npm, Yarn, and pnpm projects — often all three on the same machine — keeping track of which cache is where and which command to run gets tedious. Crumb finds all three caches in a single scan and shows you their sizes in one place, so you can clear whichever ones have grown large without switching between package managers or looking up paths. It also catches other developer caches (CocoaPods, Gradle, Homebrew downloads) in the same pass.
If you prefer staying in the terminal, the commands above are all you need and are safe to run on macOS 12 through 26. Download Crumb if you want a visual overview of what is actually taking space across your whole Mac — package caches included.
Conclusion
Clearing your npm, Yarn, and pnpm caches is low-risk routine maintenance on a development Mac. Use npm cache clean --force and yarn cache clean to wipe their respective caches completely, and prefer pnpm store prune over deleting the entire pnpm store. All three caches rebuild automatically on the next install — the only cost is a slower first install afterward. Check your cache directories first with du -sh so you know how much space you are actually reclaiming before you pull the trigger.