How to delete node_modules safely, in one project or all of them

Why node_modules gets so big

Every JavaScript project installs its dependencies into its own node_modules folder, along with the dependencies of those dependencies. Some packages also include compiled binaries for your platform. One project's folder is often bigger than its source code.

The real problem is the number of projects. Every tutorial, prototype, client project and cloned repository keeps its node_modules after you stop working on it. Nothing removes them for you, so they pile up in your projects folder for years.

…/node_modules

Node.js packages

What it is

Packages a JavaScript project installed with npm, Yarn, pnpm or Bun.

Does it come back?

Comes back when it's needed

Without it

The project won't run until you install them again, for example with npm install.

pnpm works differently. It keeps one copy of each package version in a shared store (~/Library/pnpm/store on macOS) and links the files into each project's node_modules, "consuming no additional disk space," as its documentation puts it (pnpm). Size tools can still count those files once per project, so a pnpm project's folder can look bigger than the space you'd get back.

Is it safe to delete node_modules?

Yes, for your own projects. node_modules is generated. npm's own npm ci command removes an existing node_modules before every install (npm Docs).

What makes it safe is the lockfile: package-lock.json, pnpm-lock.yaml, yarn.lock or bun.lock. It records the exact version of every package, so reinstalling gives you the same tree. A few situations need a moment's thought:

• No lockfile. A fresh install may pick newer versions than you had.
• Private registries or offline work. You need access to the registry to reinstall.
• Hand edits inside node_modules. They're lost. Tools like patch-package keep such fixes outside the folder for this reason.
• Packages with install scripts. Native modules are rebuilt on install, which takes longer and needs the build tools they expect.

Delete node_modules in one project

Stop any dev server or watcher running in the project first. Then use Finder: select the node_modules folder and press ⌘Delete to move it to the Trash.

In Terminal, from the project folder, macOS 15 and later have a built-in trash command:

trash node_modules

Or delete it permanently:

rm -rf node_modules

rm -rf skips the Trash and can't be undone, so make sure you're in the right folder. When you come back to the project, reinstall:

npm ci

Use pnpm install, yarn install or bun install for projects that use those package managers.

Find every node_modules folder and its size

Point find at the folder where you keep your projects. These examples use ~/Code. To list every node_modules with its size, biggest last:

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

-prune stops find from looking inside each node_modules it finds, so nested ones aren't listed separately and the search stays fast.

Don't run this on your whole home folder and then delete everything it finds. Apps and tools keep node_modules folders they need to run, for example in ~/Library, in editor extension folders such as ~/.vscode, and in your global npm folder at $(npm prefix -g)/lib/node_modules. Deleting those breaks the app or tool, not a project.

Delete node_modules recursively

Once you know which projects to clear:

1. 1

   Stop dev servers and watchers

   Quit anything running from the projects you'll clear, such as dev servers, test watchers and editors' language servers.

2. 2

   List every node_modules folder with its size

   In Terminal, run find ~/Code -type d -name node_modules -prune -exec du -sh {} + | sort -h, using the folder where you keep your projects. The biggest are listed last.

3. 3

   Choose the projects to clear

   Pick projects you aren't working on. Check that each has a package.json and a lockfile, so you can reinstall the same versions later.

4. 4

   Move those node_modules folders to the Trash

   On macOS 15 or later, run trash followed by each folder's path, or narrow the find command to those projects and end it with -exec trash {} +.

5. 5

   Empty the Trash, and reinstall when you return

   Empty the Trash when you're sure. When you open a project again, run npm ci, pnpm install, yarn install or bun install in it.

To move every node_modules under one folder to the Trash, for example a folder of old projects:

find ~/Code/archive -type d -name node_modules -prune -exec trash {} +

The permanent version replaces trash with rm -rf:

find ~/Code/archive -type d -name node_modules -prune -exec rm -rf {} +

This deletes every match immediately, skips the Trash and can't be undone. Run the listing command with the same path first and read the output.

Using npkill

npkill is an open-source, MIT-licensed tool that does the listing and deleting interactively. Run it from your projects folder:

npx npkill -d ~/Code

It lists every node_modules with its size and when the project was last modified. Move with the arrow keys and press Space or Delete to remove the selected folder. Folders that installed apps rely on are marked with a warning sign, and --dry-run lets you try it without deleting anything. On macOS it removes folders with rm -rf (source), so they don't go to the Trash.

Package manager caches are separate

Deleting node_modules doesn't touch your package managers' download caches. npm keeps its cache in ~/.npm, pnpm in its store, Yarn in ~/Library/Caches/Yarn or ~/.yarn/berry/cache, and Bun in ~/.bun/install/cache. That's why reinstalling is usually quick.

Each tool has its own command to clear its cache. npm's is npm cache clean --force, and its documentation says clearing the cache should never be necessary "for any reason other than reclaiming disk space" (npm Docs). For pnpm, pnpm store prune removes packages no project uses, and pnpm calls it "not harmful" (pnpm). With pnpm, that's where the space from deleted node_modules folders actually comes back.

Other build folders work the same way

node_modules has relatives in every ecosystem. Each is rebuilt from a file in the project:

dist and build folders deserve a look before you remove them. In some projects they're the output you ship or the only copy of a release.

What's safe to remove, and what isn't

Safe:

• node_modules in your own projects that have a lockfile
• Framework caches such as .next and .turbo
• Package manager caches, if you accept slower installs for a while

Think first:

• Projects with no lockfile, or that need a private registry
• dist or build folders that might be your only copy of a build

Leave alone:

• node_modules inside ~/Library, app bundles and editor extension folders
• Your global packages in $(npm prefix -g)/lib/node_modules
• Anything in a project you're running right now

How MacClearings does it

MacClearings finds node_modules and the other build folders above with one Suggestions rule, Project build artifacts. It runs on your home folder and lists each folder under its project's name with its size.

Suggestions rule · Project artifacts

Project build artifacts

Dependencies and build output inside your projects (node_modules, target, .venv, ...). Your source code isn't touched; reinstall or rebuild to get them back. Projects untouched for 30 days are checked.

Listed, but you decide whether to check it.

It's careful about what counts:

• Only next to the file that proves it. node_modules counts only beside a package.json, target only beside a Cargo.toml or pom.xml, and so on. A folder that just happens to be called build isn't listed.
• Never inside apps or tools. It skips ~/Library, app bundles and hidden folders such as editor extensions, and never looks inside a node_modules for another one.
• Active projects stay unchecked. A project's build folders are checked for you only if the files and folders at the top of the project haven't been modified for 30 days, not counting the build folders themselves. Recent ones are listed for you to decide. You can change the 30 days in Settings > Cleanup.

Nothing moves until you open Review & Clean Up… and click Move to Trash. Right before moving, MacClearings checks each folder again and skips any that changed since it was measured or that a running process has open, such as one a dev server is using. Every cleanup can be undone from History. MacClearings never empties the Trash, so the space comes back when you empty it.

Duplicates knows about build folders too: copies inside build, .build, DerivedData, .next or .gradle folders are tagged Build output, so you can tell them apart from your own files.

The developer page lists every build folder MacClearings recognizes and the file it looks for beside each one.