node_modules, target/, and the slow bleed of dev cache bloat

If you've been writing software for more than a year, your Mac is almost certainly holding dependency and build caches for projects you haven't opened in months. Individually they're forgettable. Together, they're often the single biggest reclaimable chunk of space on a developer's machine.

Every `npm install` in a JavaScript project creates its own node_modules — often several hundred megabytes, sometimes more with modern monorepo tooling. Every `cargo build` in a Rust project grows a target/ directory that can hit double-digit gigabytes on larger crates. Python projects leave behind virtualenvs and __pycache__ directories. Frontend frameworks leave .next or .nuxt build output sitting around after every build. Mobile and native tooling adds Gradle and CocoaPods caches on top.

None of this is a bug — it's how these toolchains are supposed to work. The problem is that nothing ever prompts you to clean it up once a project is done, archived, or abandoned.

Dependency and build caches are, by definition, regenerable — the folder gets rebuilt automatically the next time you run install or build in that project. That's exactly why grouping and bulk-selecting these caches by category, rather than deleting individual files, is the practical way to reclaim this space: you're not making thousands of tiny judgment calls, you're clearing folders you already know how to regenerate.

Reclaim's Dev Cleanup view finds node_modules, Python caches, Rust target/ directories, JS build output, Gradle caches, and CocoaPods Pods/ directories across your whole disk, groups them by category, and lets you bulk-select per group — and every deletion still goes to Trash first, never straight to `rm`.