node_modules everywhere: how to find them, clean them and get them back

A node_modules folder holds the dependencies installed for one JavaScript or TypeScript project, and a typical one is a few hundred megabytes. With dozens of old projects, they easily add up to tens of gigabytes. They are safe to delete as long as you keep package.json and the lockfile: your package manager reinstalls the same versions when you return to the project.

Find every node_modules folder and its size

This command searches your home folder, skips ~/Library and the Trash, and prints each node_modules folder with its size, largest last:

find ~ \( -path "$HOME/Library" -o -path "$HOME/.Trash" \) -prune -o -type d -name node_modules -prune -print0 2>/dev/null | xargs -0 du -sh 2>/dev/null | sort -h

How it works: the first -prune skips the two excluded folders, -type d -name node_modules matches the folders, and the second -prune stops find from descending into them, so nested node_modules are counted once, inside their parent. du -sh measures each one and sort -h orders the list. It only reads. On a large home folder it can take a few minutes, and Terminal may ask for access to Documents, Desktop or Downloads.

Ignore results inside tool folders such as ~/.nvm, ~/.vscode or ~/.cursor. Those belong to installed tools and editor extensions, not to your projects.

If your projects use pnpm, the sizes shown are larger than what you would get back. The reason is explained further down.

Delete the ones you don’t need

Before deleting, open the project folder and check that it has a lockfile: package-lock.json (npm), pnpm-lock.yaml (pnpm), yarn.lock (Yarn) or bun.lock / bun.lockb (Bun). Keep it, and keep package.json.

The safest way to delete is to drag node_modules to the Trash in Finder. You can still change your mind until you empty the Trash. With many small files, moving to the Trash takes a moment.

From Terminal, inside one project folder:

cd ~/Projects/old-app
rm -rf node_modules

rm -rf deletes permanently, without the Trash. Check the folder you are in with pwd first, and never run it with a wildcard or an empty variable.

npkill: an interactive alternative

npkill lists node_modules folders with their sizes and lets you delete them one keystroke at a time:

npx npkill -d ~/Projects

-d sets where the search starts; without it, npkill starts in the current folder. Move with the arrow keys and press Space or Del to delete the selected folder. npkill deletes immediately, without the Trash. It marks with ⚠️ folders that apps need to run, which you should leave alone. --dry-run simulates deletion if you want to try it first.

Reinstall when you return to a project

Use the command that installs exactly what the lockfile says:

npm ci requires a lockfile, removes any existing node_modules first and never changes package.json or the lockfile. A plain npm install also works but may update the lockfile.

Other folders that rebuild themselves

Frameworks and build tools keep caches and outputs next to node_modules. These are safe to delete in projects you are not running; the next build or dev server recreates them.

dist and build are usually build output too, but the names are generic. Some projects commit files there or use them for something else, so look inside before deleting.

To list the framework caches in a projects folder:

find ~/Projects -type d \( -name .next -o -name .nuxt -o -name .svelte-kit -o -name .turbo -o -name .parcel-cache \) -prune -print0 | xargs -0 du -sh | sort -h

Clear the global package caches

Each package manager also keeps a download cache shared by all projects. Clearing it is permanent but harmless: packages download again when needed.

npm cache clean --force
pnpm store prune
yarn cache clean
bun pm cache rm

• npm keeps its cache in ~/.npm/_cacache. The npm cache docs explain why clean needs --force and note that npm cache verify garbage-collects without emptying everything. Packages fetched by npx sit in ~/.npm/_npx.
• pnpm keeps its store in ~/Library/pnpm/store on macOS (pnpm store path shows yours). pnpm store prune removes only packages no project references, and the pnpm docs suggest running it occasionally rather than constantly.
• Yarn Classic caches in ~/Library/Caches/Yarn. For Yarn Berry, yarn cache clean --mirror empties the global cache in ~/.yarn/berry/cache.
• Bun caches in ~/.bun/install/cache; bun pm cache rm empties it.

Old Node.js versions installed with nvm also add up in ~/.nvm/versions/node; nvm uninstall <version> removes one you no longer need.

Why pnpm frees less than du says

npm and Yarn Classic copy every package into each project’s node_modules. pnpm stores each package once, in a content-addressable store, and links its files into every project that uses it. On macOS, pnpm’s default packageImportMethod tries APFS clones first, then hard links.

Either way, the bytes are shared. du still counts the full size in each project, so deleting a pnpm project’s node_modules usually frees much less than it reported. The space comes back when pnpm store prune removes packages that no remaining project uses. The store has to be on the same disk as the project for this to work; projects on an external drive get their own store there.

How MoreRoom helps

MoreRoom’s free version finds node_modules folders in projects that have a lockfile and have not been touched for 30 days, plus framework caches such as .next and .turbo, and marks them “Safe to remove”. It skips ~/Library and tool folders like ~/.nvm and ~/.vscode. You move items to the Trash one at a time, with Undo. For the npm cache and the pnpm store, MoreRoom runs npm cache clean --force and pnpm store prune; those commands are permanent and labelled as such.

MoreRoom Pro adds Project hibernation: inactive projects drop rebuildable folders such as node_modules and build output, and wake again in one click when you return. Pro also includes the Collector and Goal mode.