Clearing package manager caches, safely

The right command for npm, pnpm, yarn, bun, uv, pip, cargo, go, Maven, Gradle, NuGet, vcpkg and Conan — and why you should clear them less often than you think.

Updated 2026-09-20

Package manager caches are the least dangerous thing on your disk to delete and the most frequently deleted for the wrong reason. Everything in one re-downloads. Nothing in one is unique. The catch is what a cache is for, which is making every other cleanup cheap.

The commands

Use the manager's own subcommand where one exists. It knows which parts of its cache are reconstructible and which are indexes it would rather rebuild itself:

npm cache clean --force
          pnpm store prune
          yarn cache clean
          bun pm cache rm
          uv cache prune
          pip cache purge
          go clean -modcache
          go clean -cache

Some managers have no such command, and the honest answer there is a deletion. These are directories, and removing them is exactly what the manager would do if it had a flag for it:

rm -rf ~/.cargo/registry/cache
          rm -rf ~/.cargo/registry/src
          rm -rf ~/.m2/repository
          rm -rf ~/.gradle/caches
          rm -rf ~/.gradle/wrapper/dists

On Windows PowerShell:

Remove-Item -Recurse -Force $env:USERPROFILE\.cargo\registry\cache
          Remove-Item -Recurse -Force $env:USERPROFILE\.m2\repository
          Remove-Item -Recurse -Force $env:USERPROFILE\.gradle\caches

The two cargo directories are not the same

~/.cargo/registry/cache holds the downloaded .crate archives. ~/.cargo/registry/src holds those archives unpacked. Deleting src/ is nearly free — cargo re-extracts from cache/ without touching the network. Deleting cache/ means downloading again. If you want space back cheaply, delete src/ and leave cache/ alone.

pnpm's store is not really a cache

The pnpm store is content-addressed and hardlinked into every node_modules on the machine. That is what makes a pnpm install nearly instantaneous. pnpm store prune removes only entries no project references any more, which is the right command; deleting the store directory outright turns your next install in every pnpm project into a full download.

Why you should do this less often

Here is the thing worth internalising: the cache is the reason deleting node_modules is cheap. Clearing thirty node_modules directories with a warm cache costs you a few seconds of hardlinking per project. Clearing the cache in the same sitting turns every one of those restores into a network round trip, and now you have spent an afternoon reclaiming space that would have come back anyway.

So: clear dependency directories often; clear caches rarely, and separately, and when you actually need the space rather than as part of a routine.

Seeing all of them at once

This is why dev-prune never touches a cache during a prune, and instead gives caches their own command:

devp caches

It reports sixteen caches across thirteen managers — npm, pnpm, yarn, bun, uv, pip, cargo, go, Maven, Gradle, NuGet, vcpkg and Conan — with the size of each and the exact command that clears it, asking the manager itself where its cache lives rather than guessing at a path. devp caches clear <manager> empties one when you type it, after showing what goes and asking. A shared cache cannot be proven recoverable by any one project's lockfile, so it is never part of an automatic pass. That is the whole design.