Language toolchains & SDKs

How to Find and Delete Old node_modules, target, and venv Folders (2026)

If you have been coding on macOS for more than a year, your home folder is almost certainly hiding hundreds of gigabytes of abandoned build artifacts. The culprits are always the same: node_modules directories from Node.js projects you finished in 2023, target folders left over from Rust or Java builds, and venv or .venv directories from every Python experiment you ever ran. Learning how to delete old node_modules folders on Mac — along with their cross-language equivalents — is one of the highest-leverage disk-recovery tasks you can do as a developer.

Why Build Folders Accumulate So Fast

Package managers and build tools are designed to be fast, not tidy. When you run npm install, cargo build, or python -m venv venv, the tool writes files to disk and never checks back. It has no concept of "this project is archived." Over a few years, a typical developer's machine ends up with dozens — sometimes hundreds — of these directories, each ranging from a few megabytes to several gigabytes. They sit inside old clones, archived zip extractions, and half-finished side projects buried three folders deep.

  • node_modules — the most notorious offender. A single React app can pull in 300 MB. A monorepo with workspaces can exceed 2 GB.
  • target — Rust and Maven both use a target directory. A compiled Rust binary with its debug symbols can top 1 GB on its own.
  • venv / .venv / env — Python virtual environments replicate the entire interpreter and every installed package. A data-science project with NumPy, Pandas, and PyTorch can exceed 3 GB.
  • .gradle / .build / dist / .next / __pycache__ — Gradle caches, Swift Package Manager build products, and framework-specific output folders compound the problem further.

Is It Safe to Delete These Folders?

In most cases, yes — but the answer depends on whether you can regenerate the contents.

  • Safe to delete if the project has a package.json, Cargo.toml, requirements.txt, or equivalent lockfile. You can always run npm install, cargo build, or pip install -r requirements.txt to restore the folder exactly.
  • Caution if the project has no manifest file, or if you have manually installed packages that are not captured in a lockfile. Deleting the folder means losing those undocumented dependencies.
  • Do not delete a venv if it is the only record of what packages a script needs and there is no requirements.txt alongside it. Export first: pip freeze > requirements.txt.

Cleaning is permanent unless you have a Time Machine backup. Verify before you remove.

How to Find All node_modules Folders from the Terminal

The find command is the most reliable cross-version approach and works identically on macOS 12 through macOS 26 (Tahoe).

List every node_modules directory under your home folder

find ~ -name "node_modules" -type d -prune 2>/dev/null

The -prune flag prevents find from descending into a found directory, so nested node_modules inside node_modules are not listed separately — only the top-level one is shown.

Show the disk usage of each result

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

This will take a minute but gives you a size next to every path, so you can spot the multi-gigabyte ones immediately.

Delete a specific folder

rm -rf ~/Projects/old-app/node_modules

Always provide an explicit path. Never run rm -rf with a wildcard unless you are absolutely certain of the expansion.

Finding and Deleting target, venv, and Other Build Folders

The same pattern works for every other artifact type. Adjust the -name argument:

# Rust / Maven target directories
find ~ -name "target" -type d -prune -exec du -sh {} \; 2>/dev/null

# Python virtual environments (common names)
find ~ \( -name "venv" -o -name ".venv" -o -name "env" \) -type d -prune -exec du -sh {} \; 2>/dev/null

# Swift Package Manager build products
find ~ -name ".build" -type d -prune -exec du -sh {} \; 2>/dev/null

# Next.js / Nuxt output
find ~ \( -name ".next" -o -name ".nuxt" -o -name "dist" \) -type d -prune -exec du -sh {} \; 2>/dev/null

For a bulk delete, pipe the results to xargs:

# Delete ALL venv folders under ~/Projects — review the list first!
find ~/Projects -name "venv" -type d -prune | xargs rm -rf

Comparison: Terminal vs. Dedicated Tools

Approach Effort Visual size overview Leftover file detection Undo safety
find + rm -rf Medium — requires typing and careful review None (text only) No None (immediate delete)
npkill Low for node_modules only Minimal No None
Crumb (Visualize + Uninstall) Low — point and click Full disk map with sizes Yes (leftover checker) Recoverable removal for Pro; always shown before delete

Using Crumb to Find and Remove Stale Build Folders Visually

If you prefer not to piece together a find pipeline, Crumb can surface these folders through its Visualize tab, which builds a full disk map of your Mac and highlights the largest directories by size. You can see your entire ~/Projects tree laid out with sizes, spot the bloated node_modules and target directories at a glance, and remove them from the same interface — without opening a terminal.

Crumb also includes an "Is this safe to delete?" AI feature. If you are unsure whether a particular folder is a dependency store or something your project generates dynamically, you can ask directly and get a plain-language explanation of what the folder is and what happens if you remove it. For projects you are genuinely done with, that extra confirmation step removes the guesswork. You can download Crumb and run a free cleanup to see how much space your old project artifacts are consuming.

Preventing Build Folder Bloat Going Forward

A few habits prevent the problem from compounding:

  1. Delete before archiving. When you finish a project, run npm ci --omit=dev or just rm -rf node_modules before you zip the folder or push a final tag. The manifest file is enough to restore it later.
  2. Use global tool caches. Tools like pnpm and uv (the modern Python package manager) use a shared content-addressable store instead of per-project copies, dramatically reducing duplication.
  3. Set a quarterly cleanup reminder. Build artifacts are not urgent, so they get ignored. A calendar reminder every three months to run the find commands above takes about ten minutes and typically recovers several gigabytes.
  4. Keep a projects root. Keeping all code under a single directory like ~/Projects or ~/Code makes find scans faster and easier to scope safely.

Quick Reference: Folder Types by Ecosystem

Ecosystem Folder name(s) Typical size Safe to delete?
Node.js / npm / pnpm / yarn node_modules 100 MB – 3 GB Yes, if package.json + lockfile present
Rust (Cargo) target 500 MB – 4 GB Yes — Cargo rebuilds on next cargo build
Python venv, .venv, env 50 MB – 5 GB Yes, if requirements.txt present
Java / Kotlin (Maven / Gradle) target, .gradle, build 200 MB – 2 GB Yes — regenerated by the build tool
Swift / Xcode .build, DerivedData 200 MB – 6 GB Yes — Xcode rebuilds automatically
Next.js / Nuxt / Astro .next, .nuxt, dist 50 MB – 1 GB Yes — regenerated on next build

Conclusion

Dead build folders are one of the most recoverable forms of disk waste on a developer's Mac. A targeted find command can locate them in seconds, and removing them from projects that have lockfiles is entirely safe. Whether you prefer working in the terminal or want a visual map of where the gigabytes are hiding, the process is straightforward once you know what to look for. Start with ~/Projects or wherever you keep your code, sort by size, and work from the top down — you will likely free up more space in an afternoon than any other cleanup task delivers.

Reclaim your disk in one click

Crumb audits your whole Mac, tells you what's safe to delete, and frees the space in seconds — private, local, and Apple-notarized.

Download Crumb for macOS

Frequently asked questions

Is it safe to delete node_modules on Mac?
Yes, in almost all cases. As long as your project has a package.json and a lockfile (package-lock.json or yarn.lock), running npm install or npm ci will restore node_modules exactly. The folder is generated, not authored — deleting it loses nothing unique.
How do I find all node_modules folders on my Mac at once?
Open Terminal and run: find ~ -name "node_modules" -type d -prune -exec du -sh {} \; 2>/dev/null — this lists every top-level node_modules directory under your home folder along with its size.
What is the difference between npkill and using find to delete node_modules?
npkill is an interactive Node.js-based CLI tool that focuses exclusively on node_modules. The find command is built into macOS and works for any folder name — node_modules, target, venv, .next, etc. — without requiring Node.js to be installed.
Can I bulk-delete Python venv folders safely?
Yes, if each project has a requirements.txt or pyproject.toml that captures the installed packages. Run pip freeze > requirements.txt inside any venv that lacks one before deleting it, so you can recreate the environment later.
How much disk space can I expect to recover?
It varies widely. Developers with several years of archived projects commonly recover 20–100 GB. Rust target directories and Python virtual environments for data-science projects are frequently the largest offenders.