node_modules and build output: the 66 GB most developers never look at

Guide · 6 min read · Updated September 2026

Dependencies are the clearest example of storage you already own but never see. Every clone, every experiment, every project you abandoned in 2023 still carries its full dependency tree.

On the Mac these guides are written from, dependency folders came to 46 GB and stale build output added another 20 GB across 42 forgotten .next caches.

Measure before you delete

Scope the search to where your code actually lives. Searching all of $HOME wastes minutes traversing Library and returns noise:

find ~/Projects -type d -name node_modules -prune -print0 \
  | xargs -0 du -sh | sort -rh | head -20

The -prune matters. Without it, find descends into every nested dependency tree and the run takes far longer for an identical result.

The deletion that breaks things

Build output is safe to remove from your own projects. Inside a dependency it is a different thing entirely.

A dist or build folder inside node_modules is the published package. It is what your import actually resolves to. Deleting it does not free regenerable space, it breaks the library until the next install.

The same applies to site-packages and vendor. Any sweep that matches directory names alone will eventually hit one of these. Dustloft's build-output scan explicitly skips anything inside node_modules, .venv, site-packages or vendor for exactly this reason, and its project scans only ever run inside project roots you have configured — never across $HOME or /.

What regenerates, and at what cost

What	Restored by	Real cost
node_modules	npm i / pnpm i / yarn	Network and time; lockfile keeps versions identical
.next, dist, build (your project)	Next build	One slower build
.venv, venv	pip install -r	Network and time
Package manager caches	Next install	Re-download once

Package caches are separate

Deleting node_modules does not touch the package manager's own cache. Those live outside your projects — ~/.npm/_cacache, ~/Library/Caches/pnpm, ~/.yarn/cache, ~/.bun/install/cache, ~/.cargo/registry/cache, ~/.m2/repository, ~/.gradle/caches — and they persist across every project. They are regenerable too, at the price of re-downloading on the next install.

The rest of the picture

Xcode leftovers and Docker's disk image are the other two that dominate developer machines, and repository history is worth understanding before you delete any project folder wholesale.