DevSweep: When 256GB Is No Longer Enough

A few months ago I ran into a problem that probably sounds familiar: my MacBook M1 with its 256GB of storage was screaming "disk full" constantly. And I wasn't downloading movies or accumulating photos — I was simply developing.

The silent culprit: development caches.

Docker with its ghost images, JetBrains with its multiple IDE versions, Homebrew keeping every old version of every package "just in case", npm/yarn/pnpm with their global node_modules... The list kept growing, and my available space kept shrinking.

I tried the typical solutions: DaisyDisk, CleanMyMac, random Stack Overflow scripts. Some worked, others were too aggressive, none gave me the control I needed. So I did what any frustrated developer would do: create my own tool.

That's how DevSweep was born.

The Problem: The Hidden Debt of Development

When you develop, you accumulate garbage. It's not your fault, it's the ecosystem:

• Docker/OrbStack saves every image you've downloaded, every container you've run, every volume you've created. Result: 5–20GB of occupied space.

• JetBrains keeps old versions of IntelliJ, WebStorm, PyCharm... each with its own plugins and caches. Result: 2–5GB per IDE.

• Homebrew keeps every old version of every package you've installed. Result: 500MB–2GB.

• Node.js with npm, yarn, pnpm... each with its own global cache. Result: 5–15GB.

• Maven and Gradle downloading dependencies you'll never use again. Result: more GBs lost.

In my case, I recovered 23GB the first time I ran DevSweep. Twenty-three gigabytes of space my Mac was holding "just in case".

The Solution: An Honest CLI

I decided DevSweep had to follow three principles:

1. Safety First

I didn't want a tool that deleted things carelessly. I implemented:

• Dry-run mode: You can see exactly what will be deleted before confirming

• Explicit confirmations: For destructive operations, you must say "yes, I'm sure"

• Smart preservation: Automatically keeps the latest version of each JetBrains IDE

# See what would be deleted without touching anything
devsweep --dry-run --all

# Clean with confirmations
devsweep --all

2. Modularity and Testing

The project is structured following clean code principles:

src/
├── modules/              # Each module is independent
│   ├── jetbrains.sh      # JetBrains IDE cleanup
│   ├── docker.sh         # Docker/OrbStack
│   ├── homebrew.sh       # Homebrew
│   └── devtools.sh       # Maven, Gradle, npm, yarn, etc.
└── utils/
    ├── config.sh         # Centralized configuration
    ├── common.sh         # Shared functions
    └── menu.sh           # Interactive UI

Each module:

• Is completely independent

• Has its own test suite

• Follows the pattern: detect → validate → clean

And speaking of tests... 101 tests, 123 assertions, 100% passing. Yes, for a bash script. Using bashunit, I managed to apply TDD in Bash as if it were a first-class language.

# Run the full suite
make test

# Tests: 101 passed, 101 total
# Assertions: 123 passed, 123 total
# Time: ~11 seconds

3. User Experience

I could have made a 200-line script you run and wait for. But I wanted something more professional:

• Interactive mode: A visual menu to choose what to clean

• Colorized output: To know exactly what's happening

• Space estimates: Tells you how much you'll recover before deleting anything

• Visual progress: Progress bars and organized logs

# Interactive mode - guides you step by step
devsweep

# Direct CLI - for automation
devsweep --jetbrains --docker --homebrew

Learnings: Bash in 2026 Isn't What You Thought

Working on DevSweep made me rediscover Bash, but applying everything I know about clean code and testing.

Testing in Bash

Yes, it's possible. Bashunit allows you to write tests like in any modern language:

function test_jetbrains_cleanup_removes_old_versions() {
    # Arrange
    setup_test_environment
    create_fake_jetbrains_versions "2023.1" "2023.2" "2024.1"
    
    # Act
    cleanup_jetbrains --keep-latest
    
    # Assert
    assert_directory_exists "$JETBRAINS_PATH/2024.1"
    assert_directory_not_exists "$JETBRAINS_PATH/2023.1"
    assert_directory_not_exists "$JETBRAINS_PATH/2023.2"
}

Modularity

I separated responsibilities as in any project:

• modules/: Specific business logic

• utils/: Shared functions

• tests/: Unit test suite

Each function has a single responsibility. Each module is independent. Each test validates a specific behavior.

Make as Orchestrator

The Makefile became the center of operations:

test:           # Run tests
lint:           # Validate with shellcheck
install-local:  # Install without sudo
publish:        # Complete release workflow

I even automated the entire release process:

make publish VERSION=1.0.0
# ✅ Runs tests
# ✅ Creates tarball
# ✅ Creates git tag
# ✅ Generates Homebrew formula with SHA256
# ✅ All ready for GitHub release

The Roadmap: Toward Multiplatform

DevSweep currently works on macOS. The architecture is ready to support Windows and Linux — I just need to:

1. Adapt paths: Each OS has its own cache locations

2. Platform-specific commands: Some modules need different commands per platform

3. Multiplatform testing: GitHub Actions to validate on each OS

And this is where the magic of open source comes in.

Why I Need Your Help

This project started because I had a problem. But I know I'm not alone:

• If you have a Mac with limited storage

• If you work with Docker and watch your disk disappear

• If you have 5 versions of IntelliJ installed without knowing it

• If you want a tool that respects your system

DevSweep is for you.

But I also need:

Bug Reports

Found an edge case? Something broke? Open an issue.

New Module Ideas

What other tools accumulate garbage? We can add modules for:

• Rust (cargo cache)

• Go (go build cache)

• Python (pip cache, pyc files)

• Android Studio

• Xcode (Derived Data)

Code Contributions

Want to add Linux support? Improve the UI? Optimize a module?

The project has:

• ✅ Clear contributing guide

• ✅ Automated tests

• ✅ Modular structure easy to extend

• ✅ Makefile with all necessary commands

Stars on GitHub

If the project is useful to you, a ⭐ helps more people discover it.

Getting Started

Installing DevSweep is trivial:

# Clone the repo
git clone https://github.com/Sstark97/dev_sweep.git
cd dev_sweep

# Install locally (without sudo)
make install-local

# Run
devsweep

Or for global installation:

sudo make install
devsweep --version

First Steps

# 1. Safe mode - just see what would be deleted
devsweep --dry-run --all

# 2. Interactive cleanup
devsweep

# 3. Clean specific modules
devsweep --jetbrains --docker

# 4. Full cleanup (with confirmations)
devsweep --all

Public Roadmap

Planned upcoming features:

You can view and vote on features in GitHub Issues.

Conclusion

DevSweep was born from a personal need: recovering space on a Mac with 256GB. But it became something more:

• An opportunity to apply clean code and testing in Bash

• An open source project for the developer community

• A tool that prioritizes safety and transparency

If you've ever fought with "disk full" while developing, try DevSweep. And if you find value in the project, contribute. Whether by reporting a bug, suggesting a feature, or writing code.

The code is on GitHub. The license is MIT. The door is open.

Ready to help make DevSweep better?

Links

• Repository

• Issues

• Contributing Guide

• Releases