Find node_modules Folders Eating Mac Storage

Fifty half-finished repos. Fifty node_modules directories. 20–80 GB gone, and npm will not clean them for you. Each tree is a copy of the internet as it existed the week you ran npm install. Apple files them under Documents or Other depending on where you cloned. Settings will never say “dead Next.js apps.”

This is a Western-developer problem in the boring sense: lots of git clones on a 512 GB MacBook Pro that also holds Docker and a couple of local models. Geography does not change the folder name.

Where they hide

• ~/Projects/**/node_modules
• ~/Developer/**/node_modules
• ~/src/**/node_modules
• Old zips in ~/Downloads that someone already extracted
• Desktop copies of design-system from 2023
• ~/.npm cache (different folder, same story)

pnpm and Yarn Berry use content-addressable stores (often ~/.pnpm-store or .yarn/cache). Those can be one large block instead of fifty. Treat them as Review, not Safe.

Safe cleanup rules

• Do not delete node_modules in a repo you will npm run today. You will just wait on install.
• Prefer deleting whole dead project folders if the git remote still has the code.
• If the project is alive, rm -rf node_modules && npm install is the reset, not a mystery map delete of a nested package.
• Never sudo rm -rf from /. Recursive find-and-delete scripts are how people wipe the wrong tree.

Find them without a 20-minute find

find ~ -type d -name node_modules -prune

That works and is slow on iCloud Desktop. A treemap is faster to see: many medium rectangles with the same name.

1. Download FreeUpMac and scan Home.
2. Blocks tagged node_modules · Review are the candidates.
3. Click through to the parent repo. If package.json is from a hack day in 2022, remove the project or just node_modules.
4. Pro sends it to Trash (Bin on UK Macs). Restore if you picked the app you are demoing tomorrow.

pnpm, Yarn, Bun, npm cache

Tool	Typical leftover	Notes
npm	node_modules per repo, ~/.npm	npm cache clean --force after you have disk
Yarn classic	node_modules + ~/.cache/yarn
Yarn Berry	.yarn/cache in repo or global	Do not delete if CI expects it
pnpm	store under home	pnpm store prune
Bun	node_modules + bun cache

Prune commands free package manager caches. They do not remove node_modules in abandoned clones. You still need to find those clones.

Monorepos

A Turbo/Nx repo can have a root node_modules plus per-package folders, or a single hoisted tree. Zoom in. Deleting one nested node_modules while leaving the workspace half-installed is worse than deleting nothing. If the monorepo is active, use the package manager’s prune. If the monorepo is dead, delete from the repo root.

iCloud Desktop

If Desktop and Documents sync to iCloud, node_modules in those paths is a disaster: thousands of tiny files, sync forever, “Other” grows, battery dies. Move real projects out of iCloud-synced folders. Then delete the duplicated node_modules on disk. The map makes the duplicate obvious because you will see two similar trees.

Afterward

npm install in an active repo restores it. Dead repos stay gone. Rescan. If the drive is still tight, you are probably looking at DerivedData, Docker.raw, or Time Machine snapshots — not more JavaScript.

Free scan. Pro is $12.99 USD once for in-app Trash. Related: storage full checklist.

Next.js, Vue, and Electron

.next, dist, and out are build output, not node_modules. They can be large. They regenerate. Electron apps sometimes ship a full Chromium in node_modules/electron. If the project is dead, delete the repo. If it is alive, deleting node_modules is enough; keep source.

Python and Ruby cousins

venv, .venv, and vendor/bundle are the same pattern in other languages. The map will not always tag them as node_modules. Look for repeated medium folders next to projects. The Review mindset still applies.

Corporate npm registries

If your company uses a private registry, deleting node_modules means the next install needs VPN. Do that at the office, not on a plane, unless you like waiting.

Why not a find | rm one-liner from a forum

Because node_modules appears inside node_modules (nested), inside Docker bind mounts, and inside Time Machine local snapshots. Recursive delete from ~ is how you nuke a folder named similarly in a backup or in a running container mount. Select on a map, confirm the parent package.json, then Trash.

If JavaScript is not even your job and you still have these folders, you cloned a design system once. Delete the clone. Then go back to System Data for the rest of the grey bar.