How to Delete node_modules Across Every Project on Your Mac

Open About This Mac, click Storage, and watch a giant slab of System Data or Developer files sit there with no way to click into it. If you write JavaScript, a large part of that is almost certainly node_modules: the dependency folder that npm, Yarn, and pnpm drop into every project you have ever installed.

The problem is not any single one of them. A React or Next.js app carries 200 to 500 MB in node_modules, which feels reasonable when you are working on it. The problem is that you have twenty of these folders scattered across old side projects, client work you finished last year, and tutorials you cloned once and never opened again. Every one is still holding its full copy on disk. Nobody deletes them because nobody remembers they are there.

This guide shows you how to surface all of them at once, see exactly how much space each is using, and clear the ones you do not need, without touching a line of your actual code.

Why node_modules Quietly Fills Your Disk

node_modules is where your package manager installs every library your project depends on, plus every library those libraries depend on, all the way down. A modern front-end project pulls in hundreds of packages this way, and the tree is stored as tens of thousands of tiny files. Three things make it pile up faster than you would expect.

• Nothing is shared between projects. With npm and classic Yarn, each project gets its own complete copy of every dependency. Ten projects that all use React store React ten times.
• It is invisible in Finder by default. node_modules is not something you browse, so it never shows up when you are hunting for space. macOS counts most of it as System Data, which you cannot click into.
• Old projects never get cleaned. You finish a project, move on, and its node_modules stays exactly as heavy as the day you last ran npm install. There is no expiry.

Add it up and a working developer Mac routinely carries 5 to 30 GB in node_modules folders, sometimes far more. The encouraging part is that almost none of it is worth keeping, because every byte can be rebuilt on demand.

Why Deleting It Is Safe (and Reversible)

This is the key idea that makes the whole cleanup low-risk: node_modules is generated, not authored. You never write code inside it. It is produced entirely from two files that live in your project and are committed to Git:

• package.json lists the dependencies your project asks for.
• The lockfile (package-lock.json for npm, yarn.lock for Yarn, or pnpm-lock.yaml for pnpm) records the exact versions that were installed.

Run npm install, yarn, or pnpm install and the package manager reads those two files and rebuilds node_modules to the exact same state. That is also why nearly every project lists node_modules in its .gitignore: it is disposable by design, so it is never committed to the repository. Deleting the folder does not change your repo, your history, or your source at all.

Find Every node_modules and Its Size

Never delete before you look. The first command finds every node_modules under a folder and prints its size, largest first, so you can see what you are dealing with. Point it at wherever you keep your code. Many developers use ~/Developer, but yours might be ~/Projects, ~/code, or a few different places.

find ~/Developer -type d -name node_modules -prune -exec du -sh {} + | sort -hr

Here is what each part does:

• -type d -name node_modules matches folders called node_modules.
• -prune tells find not to descend into a node_modules once it matches one. This matters because dependencies have their own nested node_modules, and without prune you would count them twice and waste time walking millions of files.
• -exec du -sh {} + prints a human-readable size for each match.
• sort -hr puts the biggest folders on top.

The output looks something like this, and the worst offenders jump out immediately:

482M  /Users/you/Developer/old-client-dashboard/node_modules
417M  /Users/you/Developer/nextjs-experiment/node_modules
361M  /Users/you/Developer/react-native-app/node_modules
298M  /Users/you/Developer/gatsby-blog-2023/node_modules
 96M  /Users/you/Developer/cli-tool/node_modules

To see the combined total across everything, add up the sizes with a second pass. This one prints one grand total so you know how much is on the table:

find ~/Developer -type d -name node_modules -prune -exec du -sk {} + | awk '{sum += $1} END {printf "%.1f GB total\n", sum/1024/1024}'

Now you have a real number and a list. If old side projects and finished client work make up most of it, you can reclaim the bulk of that space without ever touching something you are actively building.

The One-Line Delete, and Why -prune Matters

Once you have reviewed the list and you are comfortable, the delete is the same command with rm -rf in place of du. Run it from inside your projects folder, or point it at the folder explicitly:

# from inside your projects folder
find . -type d -name node_modules -prune -exec rm -rf {} +

The -prune flag is doing real work here, not just saving time. When find matches a top-level node_modules and prunes it, it removes the whole thing without first walking into the nested node_modules inside each dependency. That keeps the operation fast and avoids find trying to descend into directories that rm -rf is deleting out from under it.

If you would rather delete a single project's dependencies, you do not need find at all. Change into that project and run rm -rf node_modules. Reinstall with your package manager when you come back to it.

npkill: The Interactive Way

If a blind delete-all makes you nervous, npkill is the friendlier option. It is a free command-line tool that scans for node_modules folders and lets you delete them one at a time from a live, sortable list. You do not install anything permanently; run it with npx:

npx npkill

It scans from the folder you run it in, shows every node_modules it finds with its size and last-modified date, and lets you move through the list with the arrow keys. Press the Delete key on any folder to remove it. You watch each one disappear and see the space come back in real time.

The reason to reach for it over a raw command is safety. Some installed apps, Spotify and Discord among them, ship their own node_modules and genuinely need it to run. npkill flags folders like these with a warning so you do not delete something that would break an app. A plain rm -rf sweep run from too high up would remove them without a word.

Which Method to Use

All three approaches remove the same folders. They differ in how much control you get and how much you trust yourself with a wildcard delete.

A good default: run the find + du command to see the list, then use npkill to delete the big ones with your eyes on each. Reach for the find + rm -rf one-liner only when you are certain the whole folder is safe to wipe, such as an archive directory of finished projects.

What to Be Careful With

node_modules cleanup goes wrong in exactly two ways, and both are easy to avoid.

• Running the delete from too high up. If you run the find command from your home folder or the drive root, it can reach into application bundles and Library folders that contain their own node_modules. Stay inside your projects directory, or let npkill flag app-owned folders for you.
• Deleting a project with no lockfile. Without a committed lockfile, reinstalling can pull newer, subtly different versions of your dependencies. For an active project that matters. Generate and commit a lockfile first, then clean.

Everything else is fair game. You cannot lose source code this way, because your code never lives inside node_modules. The worst realistic outcome of a mistake is a one-line reinstall.

Bringing a Project Back

When you return to a project whose node_modules you cleared, restoring it is a single command run from the project folder. Use whichever package manager the project uses, which you can tell from its lockfile:

npm install     # package-lock.json
yarn            # yarn.lock
pnpm install    # pnpm-lock.yaml

The package manager reads the lockfile and reinstalls the exact versions you had before. For a typical project this takes seconds to a couple of minutes, mostly depending on your connection and whether the packages are still in your local package-manager cache. That is the whole trade: you swap a bit of reinstall time for gigabytes of reclaimed disk on projects you are not touching today.

Keeping It From Filling Back Up

Clearing node_modules once is satisfying, but it grows back the next time you install. A few habits keep it from ever reaching tens of gigabytes again.

• Switch to pnpm. pnpm stores every package version once in a global content-addressable store and hard-links it into each project. Ten projects that use the same React version share a single on-disk copy instead of keeping ten. For anyone juggling several projects, this is the single biggest structural fix.
• Clear finished work as you go. The moment you wrap up a client project or shelve a side project, delete its node_modules. The lockfile stays in Git, so nothing is lost and the folder rebuilds if you ever reopen it.
• Do a size pass every couple of months. Run the find + du command on a schedule. Catching it at 8 GB is a two-minute cleanup; catching it at 40 GB is a panic when the disk fills mid-build.
• Prune your package-manager cache too. The global download cache grows separately from node_modules. npm cache clean --force, yarn cache clean, and pnpm store prune reclaim that space when it gets large.

node_modules is rarely the only thing bloating a developer Mac. Xcode DerivedData, iOS simulators, Docker images, and old build outputs pile up in parallel. If you clear node_modules and the disk is still tight, those are the next places to look. Our guide on cleaning up Xcode cache covers the biggest of those.

When a Cleanup Tool Earns Its Place

The commands above are the right tool if you live in the terminal and only care about node_modules. Where a dedicated app helps is when you would rather see every developer cache on your Mac in one view, and when node_modules is only part of the problem.

Files Magic AI includes a System Cleaner with a Developer Caches view that surfaces node_modules folders, Xcode DerivedData, and other build caches across your whole Mac in a single list, shows their sizes, and clears them with a review step so nothing goes without your say-so. It sits alongside the on-device AI file organizing and offline Magic Rename the app is built around, so reclaiming space is one part of keeping the machine tidy rather than a separate errand and a separate tool.

None of that replaces find or npkill. If you like the command line, keep using it. The app is for developers who would rather glance at one list, tick the folders they do not need, and have the same pass catch the non-Node caches too.

Frequently Asked Questions

Want the bigger picture on Mac storage beyond node_modules? Our guide on how to free up disk space on Mac covers duplicates, DMGs, and other developer caches, the Xcode cache guide handles the other big one on a developer machine, and the best Mac disk cleaner apps roundup ranks the tools that automate it.

Published July 14, 2026 · More guides · Files Magic AI