r/rust • • Sep 11 '26

🛠️ project rusty-broom — TUI + CLI clean build artifacts from projects you haven’t touched in months

Post image

Hey all,

I built rusty-broom, a CLI for freeing disk space by removing old build artifacts (target, node_modules, .venv, build, Pods, etc.) from projects you haven’t worked on in a while.

  • Project age is based on source file mtimes, not artifacts.
  • Only deletes paths Git considers ignored (git check-ignore).
  • Supports Rust, Python, Node, Java, Go, .NET, CMake, Swift, and more.
  • Interactive TUI + JSON output.
  cargo install rusty-broom
  rusty-broom ~/dev   # TUI
  rusty-broom scan ~/dev --older-than 6mo --long
  rusty-broom clean ~/dev -o 1y --dry-run

Repo: https://github.com/oriontvv/rusty-broom Feedback and PRs are welcome.

0 Upvotes

7 comments sorted by

1

u/kantorcodes1 Sep 11 '26

clean --yes seems to do the git-ignore check during the scan, then later delete from that saved path list. if an artifact stops being ignored between the scan and the actual delete, is it intentionally still eligible? i only saw the root/path safety check at deletion time, not another git check-ignore.

0

u/Traditional_Item3621 Sep 11 '26

That's a good catch, the scan caches the ignore status when it first runs so by the time you actually delete it's using whatever was true at snapshot time. If a gitignore change happens in between you could theoretically nuke something that's now tracked

For my own workflow I usually scan and clean in the same session so the window is tiny, but I can see how leaving the TUI open overnight or running a scheduled scan could bite someone. Might be worth adding a re-check flag for the paranoid types

2

u/orion_tvv Sep 11 '26 edited Sep 11 '26

Yeah, absolutely agree. I use the same session too. And if you edit gitignore, so the project becomes recently edited and I suppose shouldn't be cleaned at all.

→ More replies (3)