Can I Delete node_modules? (And When To)

What node_modules actually is

When you run npm install, Yarn or pnpm install, the package manager reads your lockfile and expands it into a directory tree of every dependency — direct and transitive. That tree is node_modules.

Nothing in it is authored by you. Nothing in it is unique. Given the same lockfile and Node version, you get the same tree back. That's why deleting it is SAFE — with one condition: the lockfile must exist and be correct.

When it's safe to delete

Delete and reinstall in the project directory:

rm -rf node_modules
npm install          # or: yarn / pnpm install

When to wait

• Mid-debug session — if you're bisecting a dependency issue, finish first. Deleting mid-investigation changes the state you're testing.
• No lockfile — without a lockfile, reinstall may pull newer semver-compatible versions and change behaviour. Generate one first: npm install --package-lock-only.
• Native modules mid-compile — node-gyp builds can leave half-compiled binaries. Let the build finish or fail cleanly before wiping.
• pnpm without understanding the store — pnpm hard-links from a global store at ~/Library/pnpm/store. Deleting node_modules is still safe; deleting the store is a different operation (see our package-manager cache guide).

Find the folders eating your disk

A single active project's node_modules might be 300 MB–2 GB. But every tutorial repo, every abandoned side project, every create-react-app experiment from 2023 still has one — and they add up fast.

find ~/Projects -name node_modules -type d -prune -exec du -sh {} \; 2>/dev/null | sort -hr

Change ~/Projects to wherever you keep code (~/Developer, ~/code, ~/work). The -prune flag avoids descending into nested node_modules inside dependencies.

For an interactive picker, npkill walks directories and lets you delete with arrow keys:

npx npkill

It defaults to your home directory — narrow the path when prompted if the scan is too broad.

Stale node_modules in project roots

The hardest ones to spot are projects you deleted from git but whose node_modules folder is still on disk — or repos you haven't opened in six months but never archived. A 500 MB folder from a hackathon you forgot about is pure waste.

Heuristic: if the parent directory hasn't been modified in months and you're not returning to it soon, delete node_modules. The reinstall cost when you do return is one command and a coffee break.

# delete node_modules in projects untouched for 90+ days
find ~/Projects -name node_modules -type d -prune | while read dir; do
  parent=$(dirname "$dir")
  if [ "$(find "$parent" -maxdepth 0 -mtime +90 2>/dev/null)" ]; then
    echo "Would delete: $dir ($(du -sh "$dir" | cut -f1))"
  fi
done

DevCleaner's Project Artifacts scanner does this automatically — it walks your configured project roots, finds node_modules folders in directories untouched for months, and lists each with its size.

Not the same as clearing npm/Yarn/pnpm caches

Deleting node_modules in ten projects frees project-local space. It does not touch the global download caches at ~/.npm, ~/Library/Caches/Yarn or ~/Library/pnpm/store — those can hold another 5–20 GB independently.

For cache locations and clean commands, see the dedicated npm, Yarn & pnpm cache guide. Think of it this way: caches speed up installs across all projects; node_modules is the per-project result.

FAQ

Does deleting node_modules break git?

No — node_modules belongs in .gitignore. It was never in version control. Your repo is unchanged.

How long does reinstall take?

Depends on project size and network. A small app: 30 seconds. A large monorepo with native modules: 5–15 minutes. Caches (~/.npm etc.) make repeat installs faster even after you wiped node_modules.

Should I delete node_modules before every git pull?

Almost never. Only when dependencies changed in ways that confuse the installer, or when you're debugging a corrupted tree. Day-to-day pulls don't need it.

What about node_modules/.cache?

That's build-tool cache (webpack, babel, vite) inside the project. Safe to delete — it regenerates on next build. Goes away entirely when you delete the parent node_modules.