node_modules is taking up space on Mac: what to delete

Published 2026-11-11

Every JavaScript project keeps its dependencies in its own node_modules folder, and the folders are rarely small. Typical sizes are 150 MB to 1 GB each, and across 30 old projects the total passes 10 GB. A node_modules folder is safe to delete when the project has a package.json and, ideally, a lockfile: npm install or npm ci rebuilds it exactly. It is not safe when you edited files inside it, linked a local package into it, or cannot reach the registry. The separate package cache is a download store and is safe to clear.

Find every node_modules folder

find ~ -name node_modules -type d -prune -not -path "*/Library/*" -exec du -sk {} + 2>/dev/null | sort -rn | head -20

This searches your home folder, skips ~/Library, and prints sizes in kilobytes with the largest first. -prune is the part most one-liners forget. Without it, find also descends into each node_modules and reports the hundreds of nested node_modules inside it, so one project fills your screen with duplicates and the total is counted twice. A search across a whole home folder can take a minute.

A read-only run on the Mac used to check this guide, limited to the Desktop, found projects of 957 MB, 369 MB and 182 MB in the top three. One 957 MB folder was a single small project. Size is a poor guide to how much work a project holds.

For readable sizes, use -exec du -sh {} + and sort -h instead. To list only the ones that have not changed lately, add -mtime +90:

find ~/Desktop ~/Documents ~/Developer -maxdepth 4 -name node_modules -type d -prune -mtime +90 2>/dev/null

That lists folders not modified in 90 days. The modification time of node_modules only changes when a package is installed or removed, so it often shows the last install date, not the last time you worked on the project. Check the project's own files before you decide it is dead.

Delete one project's node_modules

cd ~/Desktop/my-project
ls package.json package-lock.json 2>/dev/null
rm -rf node_modules

The ls check confirms a manifest and lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml or bun.lock) before you remove anything. rm -rf bypasses the Trash and is permanent. To keep it recoverable, drag the folder to the Trash in Finder, though moving thousands of small files to the Trash is slow. Come back with npm ci, which installs exactly what the lockfile lists. npm install may move versions within the ranges in package.json and rewrite the lockfile.

What this removes: installed packages and the .bin links, plus node_modules/.cache (ESLint, Babel and webpack caches). What it does not touch: source files, package.json, lockfiles, .env files, build output such as dist or .next, and the global npm cache.

What breaks if the project depended on node_modules

• No lockfile. The next install resolves the newest versions allowed by package.json, which can differ from what worked before. A package that was unpublished or deprecated since you last installed it cannot come back. This is the real risk, and it grows with the age of the project.
• Edits made inside node_modules. A quick fix applied straight to a package file is lost. If you used patch-package, the patches live in a patches folder and are reapplied on install. If you did not, they are gone.
• Linked packages. npm link and file: dependencies point at other folders on your disk. Removing node_modules removes the link only, and the other folder is untouched. Redo npm link afterwards.
• Private registries. Packages from a company registry need an .npmrc token. A fresh install without it fails with 401 or 404, and the project cannot be rebuilt on that machine until you sign in again.
• Native modules. Packages with C++ parts compile on install and need Xcode Command Line Tools and a compatible Node version. The old build worked, a fresh one may not. Check node --version against the project's .nvmrc or engines field before you delete.
• A running dev server. Stop it first. A watcher that loses its files crashes with errors that look unrelated.

Delete many at once

Print the list first and read it for projects you are still working on. Then run the delete:

find ~/Desktop -maxdepth 4 -name node_modules -type d -prune -mtime +90 -exec rm -rf {} +

That permanently removes every node_modules folder not modified in 90 days under the Desktop, to a depth of 4. There is no Trash and no confirmation. Leave out -exec to preview. The npkill tool does the same with an interactive list (npx npkill). It still deletes immediately when you press the key, and it shows the same folders you saw above.

Clear the package caches

Each package manager keeps a download cache so repeated installs skip the network. Clearing it costs bandwidth the next time you install and breaks nothing.

npm cache ls lists entries and npm cache verify checks and compacts it. On the Mac checked here ~/.npm was 1.0 GB while its _cacache subfolder was 94 MB. The rest is other npm state such as logs and the npx cache, which npm cache clean does not clear. Measure both with du -sh ~/.npm ~/.npm/_cacache.

Yarn Berry's .yarn/cache inside a project can be committed to git for offline installs ("zero installs"). Do not delete it in a project that uses that. It is part of the repository.

The pnpm and Bun gotcha

pnpm and Bun store each package once and link it into projects, using hard links or APFS clones. This makes du misleading. A project's node_modules looks like 600 MB, but most of that data is shared with the store and with other projects, so deleting one folder frees much less than the figure suggests. Deleting the pnpm store frees little as well while the projects that link to it are still installed, and after it is gone the next install downloads everything again. If you use pnpm, remove stale project folders first, then run pnpm store prune, which drops the packages no project references.

Global packages and Node versions

npm ls -g --depth=0 lists globally installed packages, which live under the Node install (/usr/local/lib/node_modules for the installer from nodejs.org, a Homebrew folder for brew's Node). Version managers keep each Node version separately: ~/.nvm/versions/node, ~/.asdf/installs. Each Node version is around 100 to 200 MB with its global packages. Remove them with the manager's own command (nvm uninstall 18), not by deleting folders.

Where Spotless fits

The Developer page in Spotless lists the npm, Yarn, pnpm and Bun caches as rebuildable downloads, with sizes. It also lists each project's node_modules, judged by how recently the project was touched: projects idle for more than 90 days can be marked safe, recently edited ones are locked, and a node_modules with no package.json beside it is marked Review. Nothing is ticked for you, and removed folders go to the Trash. Spotless cannot check your lockfile, your private registry login or whether you patched a package by hand, so read the review list for those.

Keep going

• How to clear Xcode DerivedData on Mac: Where Xcode DerivedData lives, how big it gets, the exact commands to clear it safely, and the gotchas with indexes, caches and running builds.
• How to delete iOS Simulators and runtimes in Xcode: Remove old iOS Simulator devices and downloaded runtimes from Xcode, with the commands, the folders involved and what each removal costs.
• Docker is taking up space on Mac: how to reclaim it: Why Docker Desktop holds tens of GB on a Mac, how to see what is inside, which prune commands are safe, and why the disk file may not shrink.
• How to clear the Homebrew cache on Mac: Find the Homebrew cache with brew --cache, preview what brew cleanup removes, and avoid the folders that look like cache but are your installed software.

More guides