node_modules Is Eating Your Disk. How to Reclaim It Safely

A single node_modules directory is usually a few hundred megabytes. The problem is that you have forty of them, one per project, most belonging to work you finished a year ago, and every one holds a full copy of largely the same dependency tree.

Why it grows the way it does

npm installs a full dependency tree per project by default. Two projects depending on the same version of the same library each get their own copy on disk. pnpm and Yarn's newer resolvers fix this with a content-addressed store plus hardlinks, but that only helps projects installed under those tools, and it introduces its own trap: naive disk measurement double-counts hardlinked files, so tools that are not hardlink aware will tell you that you have far more to reclaim than you do.

What is actually safe to delete

A dependency directory is reproducible from the lockfile, so deleting it is safe in the narrow sense. Two caveats matter in practice. Rebuilding needs network access, so a project you might work on offline is a bad candidate. And a reinstall resolves against the registry as it exists today, which for a project with a loose lockfile or an unpinned transitive dependency may not reproduce the exact tree you had.

The rule that holds up: delete dependency directories for projects you are not actively working on, and leave the ones you are. Build output is different, because it rebuilds locally with no network:

• Safe and local: dist, build, target, .next, .build, __pycache__, coverage, DerivedData.
• Safe but needs network: node_modules, Pods, venv, .venv, vendor/bundle.
• Regenerates but slowly: ~/.npm, ~/.cache/yarn, ~/Library/Caches/CocoaPods, ~/.gradle/caches, ~/.m2/repository.

Finding them all

The manual version is a find across your code directories, which works but gives you a list of paths and no sizes:

find ~/code -name node_modules -type d -prune -maxdepth 4

Burrow's Purge tool does this across the whole machine, groups the results by kind, shows the size of each, and marks which ones need network access to rebuild. Sizing is hardlink aware, so a pnpm store shared across a dozen projects is counted once rather than a dozen times, and the number it quotes is the number you get back.