How to delete all node_modules folders on a Mac safely

To delete all node_modules folders on a Mac safely, find them with a Finder search in the folder that holds your projects, keep the ones for projects you're working on now, and move the rest to the Trash. Check that nothing you need went with them, then empty the Trash.

Nothing you wrote lives in node_modules. It's the copy of your project's dependencies that a package manager such as npm, Yarn, pnpm or Bun installed from the project's package.json and lock file, and installing again puts it back.

What removing one costs is time, not data: the next install takes a while and may download packages again. That cost is why the projects you're in the middle of are the ones to leave alone.

A few node_modules folders aren't projects at all. Tools installed globally, apps and editor extensions keep their own, and those stay. The short guide to node_modules covers the basics; this post goes further, into finished and active projects, monorepos, lock files and how each package manager lays out its files.

What node_modules is, and why there are so many

Every JavaScript or TypeScript project keeps the packages it depends on in a node_modules folder next to its package.json. The packages those packages need come too, and the ones they need, until the whole tree is there.

A project you cloned once to try something, a tutorial you followed, a client site you finished two years ago: each kept its own folder. Nothing removes them when you stop working on a project.

Why is node_modules so big?

Because it's rarely just your dependencies. A project that lists a dozen packages in package.json can install hundreds, since each one brings its own. Frameworks, build tools, test runners and type definitions add up quickly, and some packages include compiled binaries for the platform you're on.

It's also many small files. A Next.js site with npm on one developer's Mac held about 25,000 files in node_modules, for under 20 direct dependencies. That's why moving one to the Trash, and emptying the Trash, can take a while.

How much space do they take?

Single folders range from tens of megabytes for a small script to more than a gigabyte for a large app. On a Mac with years of projects, they're often one of the largest things in your home folder that you didn't make yourself.

• Small project, a few dependencies, npm34–59 MB · Usually safe
• Node.js API server, npm216–492 MB · Usually safe
• Next.js site, npm443–525 MB · Usually safe
• Next.js app, about 90 dependencies, pnpm1,175–1,577 MB · Usually safe
• React Native monorepo root, pnpm1,639 MB · Usually safe

Sizes of real projects' node_modules folders on one Mac in October 2026, as the folders report them. pnpm's folders share their files with pnpm's store, so removing them frees less than shown.

Twenty such folders at a few hundred megabytes each is several gigabytes, and a developer's Mac often has more. Storage settings counts most of it under Documents, because it sits in your home folder, not in a system location.

Does deleting node_modules delete my code?

No. Your code, package.json, the lock file and your Git history are all outside node_modules, in the project folder around it. Removing node_modules leaves the project exactly as you wrote it, minus the installed packages.

The one exception is a change someone typed straight into a file inside node_modules, such as a quick fix while debugging. That change is lost, because the reinstall brings back the published package.

What else in a project comes back by itself?

node_modules often has neighbors that are even easier to let go. Build tools keep their output and caches in the project too: a .next folder for Next.js, .turbo/cache for Turborepo, .parcel-cache for Parcel.

These come back on the next build or start of the development server, with no install step, so they cost even less than node_modules. Their names start with a dot, so Finder doesn't show them by default, and its search skips them.

Is it safe to delete all node_modules folders?

For your own projects, yes, with the few exceptions below. The package manager can install the folder again whenever you need it, and the lock file makes sure it installs the same versions.

What do you lose, and what stays?

In the project	After removing node_modules
Your source code	Untouched
package.json and the lock file	Untouched, and used to reinstall
Git history and branches	Untouched
Installed packages	Gone until the next install
Edits made inside node_modules	Lost
Patches kept with patch-package, pnpm or Yarn	Kept, and applied again on install

When isn't it safe?

A handful of projects deserve a second look before their node_modules goes:

• No lock file. Without one, the next install picks the newest versions package.json allows, which may not be the ones the project was built with. An old project can stop building this way.
• Packages from a private registry. A company's internal packages install only while you have access to that registry. If you've left the company or the registry is gone, the folder may be the only copy you can use.
• Native modules on an old Node.js version. Some packages compile code when they're installed. If the project needs a Node.js version you no longer have, or the package no longer builds on your Mac, getting it working again can take real effort.
• Edits inside node_modules. If you know someone fixed a dependency in place and never saved the change elsewhere, keep the folder until the fix is moved into a patch.

None of these is common for recent projects with a committed lock file. They matter most for old work you might need to run exactly as it was.

Which node_modules folders should you leave alone?

Some node_modules folders belong to tools and apps, not to projects. Removing them breaks the tool until you install it again, and some can't be reinstalled the way a project can.

Where it is	What it belongs to	What to do
lib/node_modules in a Node.js installation	Packages you installed globally, such as command-line tools	Uninstall them with the package manager instead
~/Library and its folders	Apps' own data	Leave it alone
Inside an app, such as an Electron app	The app itself	Never touch: remove the whole app if you don't want it
An editor's extensions folder	Installed extensions	Remove the extension in the editor
A project folder next to package.json	That project's dependencies	Safe to remove when you're not working on it

The rule of thumb: a node_modules folder you want to remove sits next to a package.json in a project you recognize. Anything else, look before you move it.

How to find every node_modules folder in Finder

You don't need Terminal to find them. Finder's search uses Spotlight's index, which includes node_modules folders in ordinary folders.

1. Open a Finder window and go to the folder that holds your projects, such as a Developer or Projects folder in your home folder.
2. Click the search field in the toolbar, type node_modules kind:folder and press Return. The kind:folder part leaves out files whose names contain the same words.
3. Below the toolbar, next to Search:, click your projects folder's name instead of This Mac, so the search stays inside it.
4. Choose View › as List, then View › Show Path Bar. Select a result and the path bar shows where it is.

To keep the search, click Save below the search field, with Add To Sidebar selected. Finder saves it as a Smart Folder you can open from the sidebar next time, with the results up to date.

Why does the search show node_modules inside other node_modules?

Packages can have their own node_modules folder for dependencies they need in a different version. Those show up in the search too, often hundreds of them. You only need the top one in each project: the one whose path bar shows the project folder right above it.

Moving the top folder to the Trash takes everything inside it, nested folders included. Selecting nested ones as well does no harm, but it makes the list harder to read.

How do you see how big they are?

Select one node_modules folder and choose File › Get Info to see its size. To see the total of several, select them, hold down the Control key, and choose File › Get Summary Info.

In your projects folder itself, outside the search, choose View › Show View Options and select Calculate all sizes in List view. Each project then shows its size in the Size column, and you can click the column heading to put the largest first.

Can you move them to the Trash from the search results?

Yes. In the results, hold down the Command key and click each top-level node_modules you want to remove, then choose File › Move to Trash. Each one goes to the Trash from wherever it was, and Put Back returns it to the same place.

Do it in batches of a few projects at a time. A short list is easier to check than two hundred results, and it's easier to remember what you removed if something stops working.

What does Finder's search miss?

Finder's search doesn't look inside hidden folders, the ones whose names start with a dot. Copies of a project kept in such a folder, such as Git worktrees some tools create inside the project, each have their own node_modules that won't appear in the results.

It also misses anything Spotlight hasn't indexed. If a large project folder seems to be missing from the results, open it in Finder and look for node_modules next to its package.json.

How to tell finished projects from active ones

The question isn't whether a node_modules folder is safe to remove; it almost always is. It's whether you'll be annoyed when you open the project next week and have to reinstall before it runs.

Which date tells you when you last worked on a project?

Not the date on node_modules. It changes whenever packages are installed, which can happen without you touching the code, and it says nothing about when you last worked on it.

A folder's Date Modified isn't much better. It changes when items directly inside it are added, removed or renamed, not when you edit a file deeper down. Open the project and sort its source folder by Date Modified instead: the newest file there tells you when you last worked on it.

If the project is on a Git host such as GitHub, the date of its last commit or push is an even better guide.

A decision table for each project

Project	Remove node_modules?	Why
You worked on it this week	No	You'd only reinstall tomorrow
Paused for a month or two	Your call	One install to pick it up again
Finished, with its code on a Git host	Yes	Nothing to lose, and a fresh install later
Cloned once to try or learn something	Yes, or remove the whole project	You can clone it again
Old, without a lock file	Look first	The next install may pick different versions
Uses packages from a registry you've lost access to	Keep it	It may not install again

Before you remove it from a project you'll come back to

Check three things in the project folder. There's a lock file next to package.json. The lock file is committed, if the project uses Git. And the project says which Node.js version it needs, for example in an .nvmrc file or the engines field of package.json.

With those in place, a reinstall months from now gives you the same packages you have today.

What that looks like in practice

Say your projects folder holds 30 projects. Four are active, so their folders stay. Twenty are finished npm sites at about 450 MB each, which is around 9 GB back once the Trash is emptied.

The last six use pnpm. Their folders add up to several gigabytes in Finder, but removing them frees little until pnpm's store is cleaned, so they're worth doing in the same session as the store, not on their own.

npm, Yarn, pnpm and Bun: what node_modules looks like with each

Package managers don't all store packages the same way, and that changes how much space removing node_modules gives back. The lock file next to package.json tells you which one a project uses.

Package manager	Lock file	What node_modules holds	Space freed by removing it
npm	package-lock.json	A full copy of every package	All of it
Yarn Classic (1.x)	yarn.lock	A full copy of every package	All of it
Yarn 2 and later	yarn.lock	Usually no node_modules at all	Nothing, if the project has none
pnpm	pnpm-lock.yaml	Links into one shared store	Little, until the store is pruned
Bun	bun.lock, or bun.lockb before Bun 1.2	Clones of files in Bun's cache	Little, while the cache keeps them

npm and Yarn Classic: a full copy in every project

npm installs each project's packages into its own node_modules, moving shared dependencies as high up the folder tree as it can so they're stored once per project. Every project still has its own copy. Ten projects that use the same framework keep it ten times.

Yarn 1, now called Yarn Classic, works the same way. For both, the size Finder shows for node_modules is roughly the space you get back.

pnpm: one store, linked into each project

pnpm keeps each package version once, in a store shared by every project on your Mac, in ~/Library/pnpm/store. A project's node_modules holds links to those files, organized in a hidden .pnpm folder.

On a Mac, pnpm first tries to make those links as APFS clones, and falls back to hard links. Either way, a project's files and the store's files are the same data on the disk.

pnpm's documentation gives an example: a 1 MB package looks like 1 MB in the project and 1 MB in the store, but takes 1 MB in total.

So removing a pnpm project's node_modules frees very little by itself. The space comes back when pnpm's own cleanup removes packages no project uses any more from the pnpm store. pnpm has no app or button for it; its cleanup is a command.

Yarn 2 and later: often no node_modules at all

Modern Yarn, sometimes called Yarn Berry, installs with Plug'n'Play by default. Instead of a node_modules folder, it writes one loader file, .pnp.cjs, that tells Node.js where each package is. The packages stay as zip archives in Yarn's cache, shared by every project, in the Yarn global cache.

A Yarn project can still be set to use a node_modules folder, with the nodeLinker setting in its .yarnrc.yml file. If a Yarn project has a node_modules folder, it behaves like npm's; if it doesn't, there's nothing in the project to remove.

Bun: clones of its cache

Bun keeps every package it downloads in its own cache, ~/.bun/install/cache, and puts them into a project's node_modules with clonefile on macOS. Bun's documentation says the clone takes no extra space on the disk until a file in it changes.

As with pnpm, removing a Bun project's node_modules frees little while the Bun install cache still holds the same files. Removing the folders and clearing the cache together is what gives the space back. Like pnpm, Bun has no button for this: its cache is cleared with its own command.

Why Finder's numbers can mislead for pnpm and Bun

As pnpm's documentation puts it, a package looks as if it takes space in the project and again in the store. Adding up every node_modules folder and the store in Finder can give a total far larger than the space they really use.

That's not a reason to avoid removing them: it just means the gain shows up when the shared store is cleaned, not when each folder goes to the Trash.

Monorepos and workspaces

A monorepo keeps several packages, such as a website, a mobile app and shared libraries, in one repository. npm, Yarn, pnpm and Bun all support this through workspaces, and it changes where node_modules folders appear.

Why does a monorepo have several node_modules folders?

Most dependencies go into one node_modules at the root of the repository. npm, for example, links each workspace package into that root folder and installs shared dependencies there. Each workspace can still get its own node_modules for packages it needs in a different version, or for links to its own dependencies.

In one pnpm monorepo on the Mac measured above, the root folder held 1.6 GB, the web app's own node_modules about 300 MB, the mobile app's about 33 MB, and the shared libraries' folders almost nothing.

Should you remove them all at once?

Yes. The folders in a monorepo are installed together, from one lock file at the root, and they expect each other. Removing only some of them leaves the repository half-installed until you install from the root again.

Search for node_modules inside the repository, select the root folder and the workspace folders, the ones whose path bar shows a package folder right above them, and move them to the Trash together.

How do you spot a monorepo?

Look at the root of the repository. A pnpm-workspace.yaml file, or a workspaces field in package.json, means it's a monorepo. Folders named apps and packages are a common sign too, each holding several folders with their own package.json.

Copies of the same project

Every clone, copy or Git worktree of a project has its own node_modules. If you keep a second copy to test a branch, or tools create worktrees for you, each one costs as much as the original with npm, and less with pnpm or Bun.

These copies are often the easiest space to get back, because you rarely need more than one of them installed at a time.

What reinstalling costs

Removing node_modules is quick; it's the next install that takes time. How much depends on what's still on your Mac and what the project needs.

How long does it take to reinstall node_modules?

It depends mostly on the package manager's cache. If the packages are still in npm's, pnpm's, Yarn's or Bun's cache on your Mac, the install copies or links them from there and downloads less. If the cache was cleared, everything is downloaded again, which needs an internet connection and takes longer.

That's worth knowing before a big cleanup. If you plan to work on some of these projects soon, keep the caches, or clear them in a separate step. The post on npm, Yarn, pnpm and Bun caches covers where each cache lives and what clearing it costs.

Why the lock file matters more than node_modules

The lock file records the exact version of every package that was installed. With it, a reinstall gives you the same tree you had. npm's clean install, the kind build servers use, refuses to run without one, and stops with an error if the lock file and package.json disagree.

Without a lock file, the package manager picks the newest versions package.json allows. Months or years later, those can be different enough to break a build. Never remove the lock file to free space: it's small, and it's what makes node_modules safe to remove.

Lock file	Package manager	Keep it?
package-lock.json	npm	Yes
npm-shrinkwrap.json	npm, for published tools	Yes
yarn.lock	Yarn, all versions	Yes
pnpm-lock.yaml	pnpm	Yes
bun.lock or bun.lockb	Bun	Yes

npm also keeps a hidden lock file inside node_modules itself, .package-lock.json, to save reading the whole folder. It goes with the folder and comes back with the next install, so there's nothing to keep there.

Packages that build or download during install

Some packages do more than unpack files. Some include native code that's compiled when they're installed, which needs Apple's Command Line Tools or Xcode on your Mac.

Others download large files of their own. Puppeteer downloads a copy of Chrome for Testing, about 170 MB on a Mac, into ~/.cache/puppeteer. That folder is outside the project, so removing node_modules doesn't remove it.

Newer package managers are also stricter about install scripts. Recent versions of pnpm stop an install when a dependency wants to run a build script nobody has approved yet, and npm lists packages whose install scripts haven't been reviewed. An old project can need a small decision before it installs again.

What if the project needs an older Node.js version?

A project that ran on an older Node.js version may not install cleanly on a newer one, especially if it has native code. If the project names its version in an .nvmrc file or the engines field, a version manager such as nvm can install that version alongside your current one.

Those versions take space of their own, in ~/.nvm/versions/node for nvm. Removing old ones is a separate decision from removing node_modules, because each holds the tools you installed globally with it.

Mistakes to avoid

Most problems with removing node_modules come from removing too much at once, or the wrong thing next to it.

Don't remove the lock file with it

Advice to delete node_modules and the lock file together, to fix a broken install, is common. It's a fix for a specific problem, not a way to free space. A lock file is usually well under a megabyte, and without it the project's next install may not match what you built.

Don't empty the Trash straight away

Keep the folders in the Trash for a day or two after a large cleanup. If a project you forgot about stops working, select its node_modules in the Trash and choose File › Put Back: it returns to where it was, with nothing to install.

Once you're sure, click Empty at the top right of the Trash window. Emptying is permanent, and tens of thousands of small files can take a while.

Don't remove it while the project is running

Stop the project's development server, test runner or build first, and close it in your editor if the editor runs tools from it. A running server whose node_modules disappears stops working until you install again, and can leave a half-written folder behind.

Don't paste commands from a web page

Many guides suggest a one-line Terminal command that finds and deletes every node_modules under a folder. Run in the wrong folder, it removes folders you didn't mean to touch, and it skips the Trash, so nothing can be put back. Everything in this post works in Finder.

Don't remove a whole project to save space

The project folder holds your code, which may not be anywhere else. If you want a project gone entirely, check its code is pushed to a Git host or copied somewhere safe first. To free space, removing node_modules alone is usually enough.

Projects in iCloud Drive or another synced folder

If your projects live in iCloud Drive, for example in Documents with Desktop & Documents Folders turned on, removing node_modules there also removes it from iCloud and from your other Macs. For node_modules that's usually harmless, because each Mac can install it again. For anything else in the project, it's a reason to be careful.

Keep node_modules from piling up again

node_modules comes back every time you install, so the goal isn't to have none. It's to keep folders only for the projects you're actually using.

A short routine

1. Every month or two, open your saved Smart Folder for node_modules.
2. Look for projects you haven't worked on since last time.
3. Move their node_modules to the Trash, along with copies and worktrees you no longer need.
4. A few days later, if nothing is missing, empty the Trash.

Leave them out of Time Machine

Time Machine backs up node_modules with everything else, which mostly costs space on your backup disk. To leave them out, choose Apple menu › System Settings, click General, then Time Machine. Click Options, click the Add button, select the folders, then click Done.

Excluded items still appear in Time Machine's local snapshots on your Mac, according to Apple. For most projects a reinstall brings back everything you'd need, so leaving them out of backups loses nothing.

Does the package manager make a difference?

It can. pnpm and Bun keep one copy of each package version for all your projects, so ten projects using the same framework cost far less than with npm. That's a reason some developers choose them, not a reason to switch an existing project just for space: a different package manager means a different lock file.

How the app does it

Wombit finds every node_modules folder next to a package.json in your home folder, and leaves out the ones inside Library and the global installs in lib/node_modules. Select one on the map to see what it is and what removing it costs.

A project's node_modules is Usually safe: it comes back, but only when you install again. So in Cleanup it never starts checked, and nothing inside Documents or Desktop is ever checked for you. What you check goes to the Trash, where Put Back returns it.

Hard links and APFS clones count once, so the files pnpm and Bun share between projects and their store aren't added up twice. The shared stores and caches are listed on their own, with the catalog's explanation of each:

• ~/**/node_modules

  node_modules

  A JavaScript project's installed dependencies, which its package manager can install again.

  Usually safe · Moves it to the Trash

• ~/Library/pnpm/store

  pnpm store

  The shared store where pnpm keeps one copy of every package version your projects use.

  Safe · Runs pnpm store prune

• ~/.bun/install/cache

  Bun install cache

  Packages Bun has downloaded, kept in one place and reused by every project.

  Safe · Runs bun pm cache rm

Tools with their own cleanup command run that command instead of having their files deleted, after the review sheet. What a command removes can't be put back, and the sheet says so.

Finding and explaining every node_modules folder is free. Moving them to the Trash in Cleanup is PRO: one payment of $4.99 with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.