Developer cleanup

How to Bulk-Clean node_modules, target, and build Folders in Old Projects

Find regenerable dependency and build folders in old projects, clean them in bulk with commands or WashBear, and keep virtualenvs and tracked files safe.

Published 2026/10/29By WashBear Team

Measure an old project and you will often find a few dozen megabytes of source code next to hundreds of megabytes, or several gigabytes, of node_modules, Rust target, or Gradle build output. With enough projects, these regenerable folders become the largest thing on your disk. This guide helps you decide which folders are safe to delete, shows how to find them in bulk from the command line, and explains how WashBear protects your projects when it cleans them for you.

Which folders can be regenerated

EcosystemCommon foldersHow to restore
Node.jsnode_modules, .next/cache, .nuxt, .turbonpm ci, pnpm install, or yarn install
Rusttargetcargo build
Gradle, Androidbuild, .gradleBuild again
MaventargetBuild again
Swift Package.buildswift build
CocoaPodsPodspod install
Flutter, Dartbuild, .dart_toolflutter pub get, then build again
Python__pycache__, .pytest_cache, .mypy_cache, .ruff_cache, .toxRecreated automatically when tools run
PHPvendorcomposer install
.NETbin, objdotnet build

Restoring exactly what you had depends on a lockfile, such as package-lock.json, pnpm-lock.yaml, yarn.lock, Cargo.lock, Podfile.lock, or composer.lock, so that reinstalling gives you the same versions as before.

Risks to check first

  • Record dependencies before deleting virtual environments: Python's .venv and venv can be rebuilt, but only if requirements.txt or a lockfile records the dependencies. If nothing does, export them first with pip freeze > requirements.txt.
  • Some build folders contain hand-written files: a few projects keep configuration, keys, or hand-written scripts in build or target, or even commit them to Git. Check for tracked files before deleting.
  • Old projects may not install again: packages they depend on may have been unpublished, and old toolchains may no longer install. For old projects you still maintain, confirm they reinstall before deleting anything.
  • pnpm projects free less: a pnpm project's node_modules shares data blocks with the global store, so deleting it may free less space than its size suggests.

Clean up in bulk manually

Find them first

Assuming your projects live in ~/Projects, the command below lists every node_modules and target folder with its size. -prune stops find from descending into those folders, which makes it much faster:

find ~/Projects -type d \( -name node_modules -o -name target \) -prune -print0 \
  | xargs -0 du -sh 2>/dev/null | sort -h

To focus on projects you have not touched in a long time, add a time condition. A node_modules folder's modification time roughly matches the last dependency install, so treat it as a hint only:

# List node_modules folders with no dependency reinstall in the last 90 days
find ~/Projects -type d -name node_modules -prune -mtime +90 -print
# After checking the list, delete them; rm -rf bypasses the Trash
find ~/Projects -type d -name node_modules -prune -mtime +90 -exec rm -rf {} +

Use each tool's own clean command

Inside a single project, prefer the tool's own command, because it knows which files it generated:

cargo clean            # remove a Rust project's target
./gradlew clean        # remove a Gradle project's build output
mvn clean              # remove a Maven project's target
flutter clean          # remove a Flutter project's build and .dart_tool
swift package reset    # remove a Swift package's .build

Preview ignored files with Git

If a project uses Git, most of what .gitignore lists can be regenerated. git clean -X deletes only ignored files; preview with -n first:

# Preview: list ignored files and folders that would be deleted
git clean -ndX
# Run it only after checking the list
git clean -fdX

Warning

.env files, local configuration, and editor settings are usually in .gitignore too. If they appear in the preview, move them out of the way first, or use the find commands above to delete specific folders only.

Clean up in bulk with WashBear

WashBear's Deep Cleanup groups these folders under Project build artifacts, covering more than thirty tools and frameworks in items such as Node.js build artifacts, Rust build artifacts, Python build artifacts, and Gradle build artifacts. It recognizes projects by marker files such as package.json, Cargo.toml, pom.xml, and Podfile, and lists only the folders the matching tool generates. Expand an item to see each folder's path, size, file count, and last modification time, and select folders one by one.

Smart recommendation never preselects this category, and there is no automatic age filter: you decide which projects to clean.

Where WashBear looks for projects

  • Standard Scan: searches the folders in your home folder, except hidden folders and app data folders such as Library, and keeps only the most recently modified projects, judged by the project folder's modification time; currently up to 96. If you have many projects, ones you have not touched in a long time may be left out.
  • Choose Disks: the system disk is always scanned, and you can also select other disks, such as external drives, to search for projects there, without the limit above. This is the better choice for tidying up old projects.

Desktop, Documents, and Downloads are protected by macOS privacy controls; if you deny access, those locations are skipped. To protect a project, add its folder under By path in Settings → Scanning & analysis → Scan exclusions; path exclusions apply to project build artifacts.

What is skipped automatically

  • If a build folder contains Git-tracked files, a .git folder, or key files such as *-keypair.json, WashBear does not clean it, and the result shows Could not be fully read and is excluded. The same applies when the project is in a Git repository but Git is not available on this Mac.
  • Before cleaning, WashBear checks the project and folder again and skips folders that no longer qualify.
  • Python's .venv and venv are out of scope; Python build artifacts covers only tool caches such as __pycache__ and .pytest_cache. The dist and build output folders of Node.js projects are not included either.

Cleanup deletes files directly instead of moving them to the Trash, and the result is recorded in Operation History. Global npm and pnpm caches are a separate topic covered in how to clear npm, pnpm, and Yarn caches; for Xcode's DerivedData, see clearing Xcode storage.

To see how much your old projects could give back, download WashBear and run a scan; scanning alone never deletes anything. The demo below uses sample data, so its items and numbers are only illustrative.

Deep Cleanup

Macintosh HD32.76 GB available
Found 33 cleanable itemsestimated cleanable data79.3 GB
System caches
Selected / Found554 MB/ 554 MBSelect all
Old diagnostic logsLow riskOld diagnostic reports from macOS and apps 313 MB
Long-unused system cachesLow riskSystem caches not updated by you for over 7 days 241 MB
Old temporary filesLow riskTemporary files left behind by macOS and apps 394 KB
Selected items21Estimated release41.5 GB
Selection
Interactive demo · all data is simulated

FAQ

How do I restore a project after deleting node_modules?

Run the install command in the project folder, such as npm ci, pnpm install, or yarn install. With a package-lock.json, npm ci installs exactly what the lockfile specifies.

Can WashBear delete my source code?

No. It deletes only the folders its rules list, those folders must belong to a recognized project, and folders that contain Git-tracked files are skipped.

Can I clean projects on an external drive?

Yes. Click the arrow next to Start Scan, choose Choose Disks, select that drive, and start the scan.

Related articles