DEV Community: Mayne

I reclaimed 12GB from my SSD with one terminal command (and you can too)

Mayne — Thu, 18 Jun 2026 11:21:50 +0000

I've been a developer for over a decade, and if there's one thing I've learned, it's that our hard drives are basically landfills for build artifacts.

A few weeks ago, I was down to 2GB free on my main SSD. Not because I had tons of important files — but because I had years worth of node_modules folders, .next build caches, dist directories, and other junk scattered across dozens of old projects.

I tried reclaiming space manually. You know the drill — du -sh to find the culprits, then rm -rf them one by one. It works, but it's tedious. I tried npkill — it only handles node_modules. I tried wipe-modules — same limitation. I wanted something that could find everything at once and let me pick what to delete in one go.

So I built ZapDir.

What is ZapDir?

ZapDir is a terminal cleanup tool that scans your projects for heavy build artifacts and lets you delete them through a beautiful interactive interface. It's completely free, open-source under MIT, and runs on Windows, macOS, and Linux with Node.js 18+.

npm install -g zapdir
zapdir

Run that, and you'll see something like this:

⚡  ZapDir  —  Terminal Cleanup Tool

  🗑  Junk Found — Total recoverable:  1.47 GB

  ██████████  node_modules    /node_modules      245.23 MB
  ██████░░░░  .next           /.next               1.23 GB
  ██░░░░░░░░  dist            /dist                89.45 MB

  ✔  Delete 3 item(s) freeing 1.47 GB?  ·  Yes

  ✔  Freed 1.47 GB of disk space!

The colored size bars make it obvious what's eating the most space at a glance — red for anything over 500MB, yellow for over 100MB, and green for the rest.

What makes it different from npkill or wipe-modules?

There are other cleanup tools out there, but most of them only handle one pattern. Here's how ZapDir compares:

Feature	ZapDir	npkill	wipe-modules
Patterns detected	13+	1 (node_modules)	1 (node_modules)
Interactive TUI	✅	✅	❌
Color-coded sizes	✅	❌	❌
Dry-run preview	✅	❌	❌
Async scanner	✅	❌	❌
Cross-platform	✅	✅	✅

ZapDir detects: node_modules, .next, .nuxt, .turbo, dist, build, .cache, coverage, out, target, .parcel-cache, __pycache__, and .DS_Store.

What it found on my machine

I ran ZapDir across my development machine and here's what turned up:

Location	What was there	Space recovered
~/Projects/legacy-app	`node_modules` + `.next`	1.8 GB
~/Projects/side-project	`node_modules` + `build`	640 MB
~/Projects/old-tutorial	`node_modules`	420 MB
~/.cache	Various caches	340 MB
Various Rust projects	`target/` directories	2.1 GB
Old Next.js projects	`.next` caches	3.4 GB
Abandoned monorepos	`node_modules` × 5	2.2 GB
Python projects	`__pycache__` + `.cache`	180 MB

Total reclaimed: roughly 12 GB

That's 12 GB I got back without touching a single file I actually needed. The biggest wins were old Next.js projects with massive .next caches (some over 1 GB each) and Rust projects where target/ directories had accumulated to over 2 GB combined.

Is it safe?

Short answer: yes, if you use --dry-run first.

zapdir --dry-run ~/Projects

This scans and shows you exactly what would be deleted without actually removing anything. The output shows every item with its size, path, and a visual bar so you know exactly what you're getting into.

When you're satisfied with the preview, run it without the flag. You'll be prompted to confirm before anything is deleted:

✔  Delete 3 item(s) freeing 1.47 GB?  ·  Yes / No

The scanner uses fs.promises.readdir with async parallel traversal for speed, and deletion is done with Promise.allSettled so a permission error on one file won't crash the entire operation — it just skips that file and continues. I've been using it for weeks and haven't lost a single file I needed.

How the scanning works

The core logic is surprisingly straightforward. It walks directories recursively using Node.js's built-in fs.promises, matches directory names against a list of known artifact patterns, calculates sizes using a streaming iterator (to avoid memory issues on huge folders), and presents everything in an interactive selection menu powered by @clack/prompts.

Hidden directories like .git are skipped by default for speed. The entire scan of my home directory — thousands of folders — completes in under 10 seconds.

A practical tip

Here's what I do now: once a month, I run:

zapdir --dry-run ~/Projects

This gives me a quick health check of how much junk has accumulated. When the number crosses 1 GB, I run it for real and reclaim the space. It's become part of my regular maintenance routine, right alongside brew update and npm outdated.

Give it a shot

If you're running low on disk space and have old projects lying around, try it:

npm install -g zapdir
zapdir

It takes five seconds to install and could free up gigabytes. The code is open source under MIT, so you can inspect exactly what it does before running it.

⭐ Star the repo on GitHub if you find it useful — it helps other developers discover it too.

ZapDir is MIT licensed and open source. Contributions, feature requests, and bug reports are welcome on GitHub.

Blazing-fast terminal cleanup tool for heavy build artifacts

Mayne — Thu, 18 Jun 2026 08:45:25 +0000

I've been a developer for over a decade, and if there's one thing I've learned, it's that our hard drives are basically landfills for build artifacts.

So I built ZapDir.

What is ZapDir?

npm install -g zapdir
zapdir

Run that, and you'll see something like this:

⚡  ZapDir  —  Terminal Cleanup Tool

  🗑  Junk Found — Total recoverable:  1.47 GB

  ██████████  node_modules    /node_modules      245.23 MB
  ██████░░░░  .next           /.next               1.23 GB
  ██░░░░░░░░  dist            /dist                89.45 MB

  ✔  Delete 3 item(s) freeing 1.47 GB?  ·  Yes

  ✔  Freed 1.47 GB of disk space!

The colored size bars make it obvious what's eating the most space at a glance — red for anything over 500MB, yellow for over 100MB, and green for the rest.

What makes it different from npkill or wipe-modules?

There are other cleanup tools out there, but most of them only handle one pattern. Here's how ZapDir compares:

Feature	ZapDir	npkill	wipe-modules
Patterns detected	13+	1 (node_modules)	1 (node_modules)
Interactive TUI	✅	✅	❌
Color-coded sizes	✅	❌	❌
Dry-run preview	✅	❌	❌
Async scanner	✅	❌	❌
Cross-platform	✅	✅	✅

ZapDir detects: node_modules, .next, .nuxt, .turbo, dist, build, .cache, coverage, out, target, .parcel-cache, __pycache__, and .DS_Store.

What it found on my machine

I ran ZapDir across my development machine and here's what turned up:

Location	What was there	Space recovered
~/Projects/legacy-app	`node_modules` + `.next`	1.8 GB
~/Projects/side-project	`node_modules` + `build`	640 MB
~/Projects/old-tutorial	`node_modules`	420 MB
~/.cache	Various caches	340 MB
Various Rust projects	`target/` directories	2.1 GB
Old Next.js projects	`.next` caches	3.4 GB
Abandoned monorepos	`node_modules` × 5	2.2 GB
Python projects	`__pycache__` + `.cache`	180 MB

Total reclaimed: roughly 12 GB

Is it safe?

Short answer: yes, if you use --dry-run first.

zapdir --dry-run ~/Projects

When you're satisfied with the preview, run it without the flag. You'll be prompted to confirm before anything is deleted:

✔  Delete 3 item(s) freeing 1.47 GB?  ·  Yes / No

How the scanning works

Hidden directories like .git are skipped by default for speed. The entire scan of my home directory — thousands of folders — completes in under 10 seconds.

A practical tip

Here's what I do now: once a month, I run:

zapdir --dry-run ~/Projects

Give it a shot

If you're running low on disk space and have old projects lying around, try it:

npm install -g zapdir
zapdir

It takes five seconds to install and could free up gigabytes. The code is open source under MIT, so you can inspect exactly what it does before running it.

⭐ Star the repo on GitHub if you find it useful — it helps other developers discover it too.

ZapDir is MIT licensed and open source. Contributions, feature requests, and bug reports are welcome on GitHub.

PyChase: AST-Powered Duplicate Code Detection for Python

Mayne — Thu, 18 Jun 2026 04:49:03 +0000

The Problem: Hidden Code Duplication

Every codebase accumulates copy-paste clones. They start innocently — "I'll just duplicate this function and tweak it" — but over months they compound into a maintenance tax. When a bug is fixed in one copy, the other 5 copies stay broken. When a feature needs to change, you hunt down every variant by hand.

Traditional duplicate detectors fall into two camps:

Line-based tools (Duplo, Simian) — compare raw text, miss everything after variable renaming
Token-based tools (jscpd, PMD CPD) — slightly better, but still fail when identifiers change
Generic AST tools (SonarQube) — heavy infrastructure, Python support is an afterthought

PyChase takes a different approach: normalized AST fingerprints with MinHash + LSH.

What PyChase Catches

Clone Type	Description	Example	PyChase
Type-1	Exact copy-paste	Same code, same names	✅ 1.000 score
Type-2	Renamed identifiers	`calculate_total` → `compute_sum`	✅ 0.786 score
Type-3	Modified logic	Added/removed statements, reordered	✅ 0.620 score

How It Works

1. Parse to AST

Each .py file is parsed into a Python Abstract Syntax Tree using the standard ast module.

2. Normalize

Variable names, function names, attribute names, string literals, numbers, and docstrings are replaced with generic placeholders. This strips everything except structure:

# These two produce the SAME normalized AST:
def calculate_total(items, rate):
    subtotal = 0
    for item in items:
        subtotal += item.price
    tax = subtotal * rate
    return subtotal + tax

def compute_sum(products, factor):
    result = 0
    for product in products:
        result += product.cost
    fee = result * factor
    return result + fee

3. Shingle

The normalized AST node sequence is broken into overlapping k-shingles (default k=3):

(FunctionDef, arguments, arg) → (arguments, arg, Add) → ...

4. Fingerprint + Match

Each shingle set becomes a structural fingerprint. MinHash signatures compress these into compact 256-bit signatures. Locality Sensitive Hashing (LSH) indexes them — only units sharing a bucket are compared.

This reduces candidate pairs from O(n²) to nearly O(n). For 10,000 functions, that's 50 million comparisons avoided.

5. Cluster + Report

Connected-component clustering groups related matches. Results render as text, JSON, CSV, or an interactive HTML report with collapsible groups and syntax-highlighted code previews.

Quick Start

pip install pychase

# Scan your project
pychase .

# Generate HTML report
pychase --format html --output duplicates.html .

# JSON output for CI
pychase --json --threshold 0.85 ./src

Why MinHash + LSH Matters

Tools like dry4python compare every function against every other function — O(n²). With 10,000 functions, that's 50 million comparisons. PyChase's MinHash + LSH approach reduces this to near-linear time, making it viable for large monorepos and CI pipelines.

Comparison at a Glance

Tool	Algorithm	Clone Types	Setup	Output
PyChase	MinHash+LSH (O(n))	Type-1,2,3	`pip install`	Text, JSON, CSV, HTML
dry4python	Brute-force (O(n²))	Type-2 only	`pip install`	Text, JSON
jscpd	Token hash	Type-1,2	Node.js	Text, JSON, HTML
SonarQube	Custom AST	Type-1,2	DB + server + scanner	Web dashboard

Try It

pip install pychase
pychase --threshold 0.55 --min-lines 2 --min-nodes 10 ./src

GitHub: https://github.com/Mayne-X/PyChase

Docs: https://github.com/Mayne-X/PyChase/wiki

PyPI: [https://pypi.org/project/pychase/]