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

Guide · 6 min read · By Kapil Upadhyay at Logicspark · Published 10 September 2026 · Updated 12 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. If you do not know where your code lives any more, rank your home folder by size first and start from the largest directory.

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

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.

Common questions

Is it safe to delete node_modules?

Yes. Running the project's install command restores it exactly. The only cost is the time and bandwidth of that reinstall, which is why stale copies in projects you no longer touch are the best candidates.

How do I find every node_modules folder on my Mac?

Search within your project directories rather than the whole disk: find ~/Projects -type d -name node_modules -prune -print. Scoping it avoids traversing Library and system paths, which is slow and returns nothing useful.

Does deleting build output break anything?

Not for your own projects, where the next build regenerates it. It does break things inside node_modules, because a dist or build folder in a dependency is the compiled package that gets imported, not build output you can recreate.