Find and delete every node_modules folder on your Mac

Part of: Mac disk cleanup for developers: every cache, what it costs to rebuild (Developers)

Every JavaScript project you have installed has its own node_modules folder, and they add up. You can list them all with one find command, add up their size with another, and delete the ones from projects you no longer use. Each one can be recreated from package.json.

node_modules holds the packages a project depends on, downloaded by npm, Yarn or pnpm. It is the largest folder in many projects, and old projects keep theirs for years.

List them all

Start in the folder that holds your projects, not in your whole home folder. Searching everything is slow and scans folders you do not care about. For example, with projects in ~/Projects:

find ~/Projects -name node_modules -type d -prune

-type d limits results to folders. -prune tells find not to go inside each one it finds. Without it, the search lists every nested node_modules and takes much longer, because installed packages have their own.

Add up the sizes

To see each folder’s size and the total:

find ~/Projects -name node_modules -type d -prune -print0 | xargs -0 du -sk | sort -n

The sizes are in kilobytes. The -print0 and -0 pair keeps folder names with spaces intact. To print a total in gigabytes, pipe into awk '{s+=$1} END {printf "%.1f GB\n", s/1048576}'.

On a Mac with a few active repositories, the total was around half a gigabyte for the folders found this way. A Mac with many projects can hold far more. Check yours.

Safe, risky, never

• Safe: node_modules in a project that has a package.json and a lock file (package-lock.json, yarn.lock or pnpm-lock.yaml), when you are not working on it now. Cost: one install when you return to it.
• Risky: a project without a lock file, or one pinned to old package versions that may no longer download. A fresh install can pick different versions. Also risky: a project you must run offline soon.
• Never: do not delete a folder that you have edited by hand, for example a patched package inside node_modules. Changes made there are lost, and nothing records them. Check for a patch tool in the project before you delete.

What it costs to get it back

Run your package manager’s install command in the project. It reads package.json and the lock file and rebuilds the folder. The time depends on the project’s size and your connection. If the package manager’s cache is warm, much of it comes from disk instead of the network. See where the npm, Yarn and pnpm caches live. With pnpm, installed files are linked from a shared store, so a node_modules there is cheaper to remove and to recreate.

Which ones to remove

A simple rule: remove the node_modules of projects you have not opened this season. Keep the ones you work in every day. Also remove copies in old checkouts, build output folders and archived code.

Look at the sizes from the command above, sort by the largest, and work down the list. The top few usually hold most of the space. Check that the project folder is still the one you think it is before you delete anything.

How to delete one

1. Make sure no editor, dev server or build is running in that project.
2. Confirm package.json and the lock file are in the project folder next to node_modules.
3. Move the node_modules folder to the Trash in Finder, then empty the Trash. The space comes back only after that. See why the Trash does not free space.

Do that per project. Removing them in bulk with a script is fine once you trust the list, but test the list command first.

Related duplicates

Large node_modules folders share many identical files across projects. That is a form of duplication, but a package manager is the right tool for it, not a duplicate finder. For ordinary duplicates, see how to find duplicate files on a Mac.

Rust has a similar pattern with target folders. See Rust target folders and the Cargo cache. The overall list is in the developer cleanup guide.

Worked example: scan one folder of projects

Here is a list command with a depth limit so it stays quick:

find ~/Projects -maxdepth 3 -name node_modules -type d -prune

Expect several node_modules folders, often in separate working copies of the same project. That is a common pattern. The same project checked out several times means the same packages are stored several times. If you use Git worktrees or several clones, expect this.

The -maxdepth 3 option stops find from going deeper than three levels. Raise it if your projects are nested more deeply, and lower it if the search is slow. Set the path to your own project folder.

Find the stale ones

Size is not the only guide. Age matters too. This lists the folders in a directory, with the least recently changed first:

ls -tr ~/Projects

This command was not tested for this article. Change the path to your own. The folders at the top were touched longest ago. Cross-check them with the size list. A large node_modules in a project you last touched a year ago is the best candidate.

If something goes wrong

• The install fails after you delete it. A package version may no longer exist, or your registry login has expired. Read the error. It names the package.
• The project behaves differently after reinstalling. There was no lock file, so you got newer versions. Compare with your last commit.
• You deleted the wrong folder. If it was a node_modules, reinstall. If it was something else, restore it from the Trash.
• The total looks too low. Your search path may be too narrow, or -maxdepth too small.

When not to clean

Do not remove a node_modules folder when you are about to work offline. Do not remove it if the project cannot reinstall, for example because a package came from a private registry you cannot reach now.

Let a scan find them

DiskJoy is our product. Its scan reads your disk and lists large folders, including developer ones, without changing anything. Cleanup is not built yet, so DiskJoy does not delete node_modules or anything else today. Use the scan to see where the space is, then remove folders yourself as above.

Quick checklist

1. List with find ~/Projects -name node_modules -type d -prune.
2. Sort the sizes and note the largest.
3. Check for package.json and a lock file.
4. Move the ones you do not need to the Trash and empty it.