Finding specific things

Reclaiming space from node_modules

Updated 2026-07-31 · 4 min read

A dozen abandoned side projects can quietly hold thirty gigabytes. Spotlight will not help you find them, because it excludes exactly this.

Find every one

find ~ -type d -name node_modules -prune 2>/dev/null

-prune stops find from descending into a node_modules it has already matched, which makes an enormous difference to how long this takes.

See what each costs

find ~ -type d -name node_modules -prune -exec du -sh {} \; 2>/dev/null | sort -hr

Sorted largest first. Expect the total to be startling.

Delete the dead ones

Older than 90 days, deleted safely one at a time:

find ~ -type d -name node_modules -prune -mtime +90 -print

Check that list first, then re-run with -exec rm -rf {} + once you are satisfied. Never run the delete without reading the list — rm -rf driven by find is unforgiving.

Anything you delete comes back with npm install, so the risk is time rather than data.

Why Spotlight cannot help

node_modules is on the exclusion list macOS ships with — hundreds of thousands of tiny files that would swamp the index and pollute every result. That is a reasonable default, and it means the folders are invisible to search precisely when you want to audit them.

Tools that index everything take the other approach: include them, then demote them so they never crowd out a real result unless you ask for them specifically. In Everywhere, path:node_modules or size:>1gb finds them immediately.

The same trick for other build caches

find ~ -type d \( -name "DerivedData" -o -name ".gradle" -o -name "target" -o -name "__pycache__" \) -prune 2>/dev/null

Common questions

Is it safe to delete node_modules?

Yes. It is entirely reproducible from package.json with npm install. You lose only the time to reinstall.

Why does Spotlight ignore node_modules?

It is on macOS's default exclusion list — the file count would overwhelm the index and flood results.