If you have been staring at a disk that is uncomfortably full, is it safe to delete node_modules is one of the first questions most Mac developers ask. The short answer is yes — with a few caveats that depend on whether you are mid-build, running a local dev server, or relying on global CLI tools installed directly into a project folder. This guide covers everything from how Node resolves packages to the exact commands you need to restore what you deleted, so you can recover gigabytes of disk space without a panic moment.
What Is node_modules and Why Is It So Large?
Every time you run npm install, yarn, or pnpm install inside a project, the package manager downloads each declared dependency — plus all of their dependencies — into a folder called node_modules at the root of that project. On a typical Next.js or React project the folder can easily reach 500 MB to 1 GB. On a monorepo with a dozen workspaces, it is common to see 3–5 GB in a single folder.
The reason it gets so big is that npm historically installed deduplicated but still per-project copies of every package. Even with hoisting improvements in npm 7+ and pnpm's hard-link strategy, node_modules is still the single largest discretionary disk consumer in most developer home directories.
Where node_modules Lives on macOS
Unlike caches stored in ~/Library/Caches, node_modules folders live inside your project directories — wherever you cloned or created the repository. There is no central registry folder on macOS. This means you can have dozens of separate node_modules trees scattered across your machine:
~/projects/my-app/node_modules~/Documents/client-work/storefront/node_modules~/repos/design-system/packages/ui/node_modules
Global npm packages are different — they live in the prefix path returned by npm root -g, typically something like /usr/local/lib/node_modules on Intel Macs or /opt/homebrew/lib/node_modules on Apple Silicon Macs when Node is installed via Homebrew. Deleting a project's local node_modules does not touch global packages.
Is It Safe to Delete node_modules? The Honest Breakdown
Whether deletion is safe depends entirely on your current state. The table below summarises the most common scenarios:
| Scenario | Safe to delete? | What happens after? |
|---|---|---|
| Idle project you are not actively working on | Yes | Run npm install when you return; fully restored in minutes |
| Active project with dev server running | No | Dev server crashes immediately; stop it first |
| Project mid-build (CI or local) | No | Build fails; wait until build completes |
| Project with no package-lock.json or yarn.lock | Caution | Reinstall may pull newer semver-compatible versions; test afterward |
Globally installed CLI tool (e.g. create-react-app) |
Never delete global path | CLI command disappears until you run npm install -g again |
| Archived or abandoned project | Yes | Lock files preserved in git; you can always reinstall later |
What You Will NOT Lose When You Delete node_modules
This is the part that reassures most developers once they understand how Node package management works:
- Your source code — all
.js,.ts,.jsx,.vue, and.sveltefiles are untouched. They live outside node_modules. - Your lock file —
package-lock.json,yarn.lock, orpnpm-lock.yamlare at the project root and are committed to git. - Your package.json — the manifest of what you depend on stays right where it is.
- Your environment variables and
.envfiles — nothing in node_modules stores runtime configuration. - Any installed global CLI tools — those live in an entirely different path.
Everything inside node_modules is reproducible from your lock file and npm's registry. It is, in essence, a build artifact. Many teams .gitignore it precisely because it can always be regenerated.
How to Find and Delete node_modules Across Your Entire Mac
The real leverage is deleting node_modules from every project at once, not just one. Here is a step-by-step approach using the terminal.
Step 1: Find all node_modules folders and check their sizes
Run the following command from your home directory (or whichever root you want to scan). The -prune flag prevents descending into nested node_modules trees, which keeps the output clean:
find ~ -name "node_modules" -type d -prune 2>/dev/null | head -40To see disk usage per folder:
find ~ -name "node_modules" -type d -prune 2>/dev/null -exec du -sh {} \;Step 2: Delete from a single project
Stop any running dev servers first. Then:
rm -rf /path/to/your/project/node_modulesStep 3: Delete from every project under a directory
If all your projects live under ~/projects:
find ~/projects -name "node_modules" -type d -prune -exec rm -rf {} \;This is irreversible in the terminal — there is no Trash step. Double-check that your lock files are committed to git before running a bulk delete. Tools like a dedicated node_modules cleaner can show you a preview of what will be removed and the space recovered before anything is actually deleted.
Step 4: Restore a project
Navigate into the project directory and reinstall from the lock file:
cd ~/projects/my-app
npm cinpm ci is preferred over npm install for restoration because it reads the lock file exactly rather than potentially upgrading packages within semver ranges.
How Much Space Can You Realistically Recover?
On a typical developer Mac with four to eight active projects and several more archived ones, deleting all dormant node_modules folders recovers anywhere from 10 GB to 50 GB. The table below shows representative sizes for common project types in 2026:
| Project type | Typical node_modules size | Reinstall time (Apple Silicon, fast internet) |
|---|---|---|
| Create React App or Vite React | 250–400 MB | 30–60 seconds |
| Next.js 15 with TypeScript | 500 MB – 1 GB | 60–90 seconds |
| NestJS API | 300–600 MB | 45–75 seconds |
| Electron app | 800 MB – 2 GB | 2–4 minutes |
| Turborepo monorepo (5+ apps) | 3–8 GB | 3–7 minutes |
node_modules Is Not the Only Developer Cache Eating Your Disk
While node_modules is the most visible culprit, macOS developer workflows accumulate storage in several other locations. If you are doing a thorough cleanup, check these as well:
~/Library/Developer/Xcode/DerivedData— Xcode build artifacts that can run 20–60 GB on active iOS or macOS projects (more on that here).~/.m2/repository— Maven's local cache for Java projects.~/.gradle/caches— Gradle build caches for Android or Kotlin projects.~/.cargo/registryand~/.cargo/git— Rust crate sources downloaded by Cargo.~/Library/Caches/pipand~/Library/Caches/uv— Python package download caches.~/.docker— Docker images and layer caches, often the single biggest consumer at 20–100 GB.
A tool like Crumb can audit all of these at once and show what is safe before you delete, rather than requiring you to track down each path manually.
When Not to Delete node_modules
There are a handful of situations where leaving node_modules intact is the right call:
- Local package links — if you are using
npm linkorpnpm linkto develop a local package and consume it in another project, deleting and reinstalling breaks those symlinks. - Custom post-install patches — if you are using
patch-packageand have not committed the patches directory, the patches are innode_modules. Verifypatches/exists at the project root before deleting. - Offline environments — if your machine will lose internet access and you need the project to run, keep node_modules intact since reinstalling requires npm registry access (or a pre-configured local mirror).
Summary
Deleting node_modules is safe for any project that is not actively running, as long as you have a lock file and registry access for reinstallation. It is one of the highest-yield disk-recovery actions available to developers on macOS — a single afternoon of cleanup can free tens of gigabytes with zero permanent data loss. The restore path is always npm ci or yarn install --frozen-lockfile away. Just confirm your dev server is stopped, your lock files are committed, and you are not relying on npm link symlinks before you pull the trigger.