You know the meme. The one where node_modules is heavier than a black hole. Funny, until you're staring at a "Low Disk Space" warning on a Tuesday afternoon and wondering where 47GB of your 256GB SSD went.
Let's talk about the elephant in the directory.
Here's the thing nobody warns you about when you start building things. Every project you create, clone, or "just want to try out for five minutes" leaves behind a trail of generated files. And those files are big.
A fresh Create React App? That's 200-300MB of node_modules before you've written a single line of code. Next.js with a few dependencies? Easily 400MB+. And that's one project.
Most developers have ten, twenty, sometimes fifty projects scattered across their machine. Tutorial repos you followed six months ago. Side projects that lasted exactly one weekend. That thing you cloned to check one function and never opened again.
Do the maths. Ten abandoned React projects sitting in your ~/projects folder? That's 2-3GB of node_modules alone. Doing absolutely nothing. Just... sitting there. Eating your SSD.
And node_modules isn't even the worst of it.
node_modules gets all the attention (it deserves it), but it's got company. Here's the lineup of space-hogging dev junk that's almost certainly living on your machine right now:
node_modules/ — The big one. 200-300MB per project is typical. Complex projects with heavy dependencies can hit 500MB+. Fully regenerable with npm install.
.next/ — Next.js build cache. Can grow to 200-500MB on active projects. Contains compiled pages, webpack cache, and trace files.
build/ and dist/ — Your compiled output. Varies wildly in size, but the build caches underneath them can be substantial. Every time you run a production build, more gets cached.
__pycache__/ — Python's compiled bytecode. Individually tiny, but they breed. Scattered across every directory in every Python project. Dozens of little folders, each with .pyc files.
.venv/ and venv/ — Python virtual environments. Each one is 50-200MB depending on your dependencies. And they're completely regenerable from requirements.txt.
.gradle/ and .m2/ — Java and Android developers, you know this pain. The Gradle cache alone can be multiple gigabytes. Maven's .m2 repository is essentially a local mirror of half of Maven Central.
target/ — Rust's target directory is legendary. A single Rust project can have a target folder north of 1GB. Two or three Rust projects and you're looking at serious disk space.
.cargo/registry/ — Shared Rust package cache. Grows silently over time.
vendor/ — PHP's Composer equivalent of node_modules. Same problem, slightly less memed.
.terraform/ — Each Terraform workspace downloads provider binaries. These add up fast across multiple infrastructure projects.
If you work across multiple languages — and most of us do — you're carrying around gigabytes of regenerable junk without realising it.
Let's be conservative. Say you're a JavaScript developer with a reasonable number of projects:
| What | Count | Size each | Total |
|---|---|---|---|
| Active projects (node_modules) | 5 | 300MB | 1.5GB |
| Abandoned projects (node_modules) | 10 | 250MB | 2.5GB |
| .next build caches | 3 | 300MB | 900MB |
| Misc build/dist folders | 8 | 100MB | 800MB |
That's 5.7GB from one language. If you also dabble in Python, Rust, or Java, double it.
When we first scanned a real developer's machine during testing — someone who'd been coding professionally for about four years on the same Windows install — we found 12GB of regenerable dev files. Stuff that could be deleted and recreated with a single command in each project directory.
On a 256GB SSD where Windows and applications already eat 80-100GB, that's nearly 10% of your usable space. Gone. To files you never look at and can rebuild in seconds.
You could do this yourself. Open a terminal, navigate to each project, delete the generated folders manually.
rm -rf node_modules
rm -rf .next
rm -rf build
rm -rf distSimple enough for one project. Now do it for thirty. While making sure you don't nuke node_modules in a project you're actively working on and need to demo to a client tomorrow morning.
The manual approach has three problems:
~/projects, ~/code, ~/repos, ~/Desktop/random-tutorial, that one you cloned into Downloads...npm install again (and hoping your lockfile is intact and your private registry is accessible). Not ideal at 4pm on a Friday.Credit where it's due. There are free tools that tackle parts of this problem:
npx npkill — Brilliant little tool. Scans for node_modules directories, shows you the size of each one, and lets you delete them with a keypress. It's interactive, it's fast, and it's free. If node_modules is your only problem, this is a solid choice. Run it every month or so and you'll stay on top of things.
npx depcheck — Doesn't delete anything, but tells you which dependencies in your package.json aren't actually being used. Useful for trimming bloated dependency lists before they become bloated node_modules.
ncdu (Linux/WSL) — Not dev-specific, but a great interactive disk usage viewer. Lets you visually see what's eating space and delete from the interface.
WinDirStat or TreeSize — Windows equivalents. Show you where your disk space went. You'll still need to delete things manually, but at least you can see the damage.
These are all legitimate tools. Use them. Especially npkill — it's excellent at what it does.
Where they fall short is coverage. npkill only handles node_modules. It won't touch your .next caches, Python venvs, Rust targets, or Gradle builds. You'd need a different tool (or manual cleanup) for each language ecosystem. And none of them know whether a project is something you're actively working on or something you abandoned fourteen months ago.
This is where we come in. K8 Cruft was built because we kept hitting this exact problem across multiple languages and wanted one tool that handled all of it.
9 categories of dev junk. Not just node_modules. K8 Cruft scans for package caches, build output, virtual environments, IDE metadata, log accumulations, temp files, orphaned configs, and more. One scan, everything surfaced.
Project-aware scanning. This is the bit that matters. K8 Cruft doesn't just find big folders and offer to delete them. It understands project structure. It knows the difference between a project you committed to yesterday and one that hasn't been touched since 2024. It assigns "crap scores" based on how stale, how large, and how regenerable each item is. High crap score = safe to remove. Low crap score = probably leave it alone.
Quarantine, not deletion. Nothing gets permanently deleted. When you remove something through K8 Cruft, it goes to quarantine for 30 days. Changed your mind? Restore it. Realised you needed that .venv after all? One click, it's back. After 30 days with no complaints, then it's gone for good.
100% local. Your project files never leave your machine. No cloud upload, no telemetry, no phoning home. It runs locally, it scans locally, it deletes locally.
It's a one-time purchase at £24.95. No subscription. No "free tier with annoying upsells." You buy it, it works on your machine, that's the arrangement.
Whether you use K8 Cruft, npkill, or just your own discipline, these habits will keep dev junk from spiralling:
Delete node_modules when you shelve a project. If you're done with a project for now, nuke the node_modules. You've got a lockfile. It'll come back with npm install when you need it. There's zero reason to keep 300MB of cached packages for a project you haven't opened in three months.
Use .gitignore as a cleanup checklist. Everything in your .gitignore is, by definition, regenerable. That's literally why it's in .gitignore — because it can be rebuilt from source. When you're cleaning up, start there.
Set a calendar reminder. Once a month, spend ten minutes on dev cleanup. Run npkill. Check for stale venvs. Delete build caches from finished projects. It's less painful in small doses than doing a massive purge once a year.
Consider a projects archive. Keep active work in ~/projects and move finished/abandoned things to ~/archive. Makes it much easier to identify what's safe to clean. If it's in archive and has a lockfile, its node_modules can go.
Watch your global caches too. ~/.npm, ~/.cargo, ~/.gradle/caches, pip cache dir — these grow silently over time. They're shared across projects, so they don't show up in any single project's footprint. But they accumulate. npm cache clean --force and pip cache purge are your friends.
Your SSD is not as full as Windows says it is. A meaningful chunk of that "used space" is regenerable developer junk that's been accumulating quietly since you set up your machine.
You don't need to live with it. Whether you use free tools, paid tools, or just a terminal and some discipline, reclaiming that space is straightforward. The important thing is to actually do it — and to make it a habit rather than a once-a-year panic when your drive hits 95%.
Your disk called. It wants its space back.
K8 Cruft finds the node_modules, build caches, stale venvs, and forgotten build output that's eating your disk. Project-aware scanning, 30-day quarantine, 100% local.
See how K8 Cruft works →K8 Cruft is available at lilbuba.ai. One-time purchase, £24.95. No subscription. No cloud. Your code stays on your machine, where it belongs.