DEV Community: Asad Rajput

How to delete node_modules on Windows (safely, and for good)

Asad Rajput — Tue, 29 Sep 2026 23:22:07 +0000

If you've cloned more than a handful of JavaScript projects, there's a good chance tens of gigabytes of your drive are sitting inside folders named node_modules — most of which you'll never open again. Here's how to find them, delete them safely, and avoid the errors that make this more annoying than it should be on Windows.

Is it safe to delete node_modules?

Yes, in almost every case. node_modules holds your project's installed dependencies, not your own code. Run npm install (or yarn / pnpm install) again and it rebuilds from your package.json and lockfile. The only time to pause is if you've manually edited a file inside node_modules directly — rare, and usually a sign something else is wrong with the project anyway.

Method 1: File Explorer

The obvious way — right-click the folder, choose Delete. It works, but it's slow on large dependency trees (some packages nest hundreds of small files), and it's the method most likely to hit the error in the next section.

Method 2: Command Prompt

Faster than Explorer, and handles deeply nested folders better:

cd path\to\your\project
rmdir /s /q node_modules

/s removes all subfolders and files; /q skips the "are you sure" prompts.

Method 3: PowerShell

Remove-Item -Recurse -Force .\node_modules

Functionally similar to the Command Prompt method. Use whichever terminal you already have open.

Getting a "path too long" or "access denied" error? Windows historically capped file paths at 260 characters, and deeply nested node_modules folders (packages inside packages inside packages) blow past that easily. Two fixes: enable long path support by opening Group Policy Editor → Computer Configuration → Administrative Templates → System → Filesystem → "Enable Win32 long paths", or, faster, use robocopy to overwrite the folder with an empty one first: robocopy empty_folder node_modules /mir, then delete the now-empty result.

Method 4: npkill (finds every node_modules on your drive)

If you have dozens of old projects scattered across your drive, hunting each one down manually isn't realistic. npkill is a free command-line tool that scans your drive, lists every node_modules folder with its size, and lets you delete the ones you don't need interactively:

npx npkill

What about Docker, WSL, and everything else?

node_modules is usually just the beginning. Docker Desktop's virtual disk, WSL2's disk image, and build caches from tools like Webpack or Vite tend to grow quietly in the background too — and none of them show up clearly in Windows' own storage view.

I'm exploring building a small tool that finds all of this in one scan — node_modules, Docker images, WSL bloat, build caches — classified as safe or not, cleared in a few clicks. Still early stage: sweepdevv.netlify.app

Docker Desktop taking too much space on Windows? Here's the fix

Asad Rajput — Tue, 29 Sep 2026 23:19:50 +0000

You've run docker system prune, deleted old images, and your C: drive still hasn't gotten any smaller. This isn't a bug — it's how Docker Desktop's virtual disk works on Windows, and it needs one extra step to actually give the space back.

Why prune isn't enough

Docker Desktop on Windows runs on a WSL2 backend, storing all your images, containers, and volumes inside a single virtual disk file (a .vhdx) — typically at:

%LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx

or, on older installs:

%USERPROFILE%\AppData\Local\Docker\wsl\data\ext4.vhdx

This file grows automatically as you pull images and build containers — but it doesn't shrink back down on its own when you delete things. Windows sees the file's maximum size, not how much of it is actually in use. Pruning frees space inside the virtual disk; it doesn't return that space to your C: drive until you compact the file itself.

Step 1: Clean up inside Docker first

docker system prune -a --volumes

This removes unused containers, networks, dangling images, and volumes. Do this before compacting — there's no point shrinking a disk full of things you don't need.

Step 2: Shut everything down

The virtual disk can't be compacted while it's in use.

Right-click the Docker Desktop tray icon → Quit Docker Desktop
Open Command Prompt or PowerShell and run: wsl --shutdown

Step 3: Compact the virtual disk

If you're on Windows 10/11 Pro or Enterprise with the Hyper-V module available, open PowerShell as Administrator:

cd "$env:LOCALAPPDATA\Docker\wsl\disk"
Optimize-VHD -Path .\docker_data.vhdx -Mode Full

On Windows 10/11 Home, the Hyper-V module usually isn't available. Use diskpart instead:

diskpart
select vdisk file="C:\Users\YOURNAME\AppData\Local\Docker\wsl\disk\docker_data.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

Can't find the file, or it has a different name? Docker has changed the exact folder layout across versions. Check both %LOCALAPPDATA%\Docker\wsl\disk\ and %LOCALAPPDATA%\Docker\wsl\data\ — the file will be named either docker_data.vhdx or ext4.vhdx.

Step 4: Restart Docker Desktop

Open Docker Desktop normally — it will reattach to the (now smaller) virtual disk automatically.

Prevent it from happening again

In Docker Desktop, go to Settings → Resources → Advanced and set a disk size limit. It won't shrink the disk automatically for you, but it stops it from silently eating your entire drive between cleanups.

I'm exploring building a small tool that catches this automatically — Docker's virtual disk, WSL bloat, and node_modules clutter, all in one scan instead of hunting each one down manually. Still early stage: sweepdevv.netlify.app

WSL2 disk keeps growing? Here's how to shrink it

Asad Rajput — Tue, 29 Sep 2026 23:15:24 +0000

If you use WSL2 for any length of time, you've probably noticed this: you delete files, clear caches, even uninstall packages inside your Linux distro — and your Windows C: drive usage doesn't move. This trips up almost everyone, and it's not something you did wrong.

Why this happens

Every WSL2 distro lives inside its own virtual disk file (a .vhdx), usually somewhere under:

C:\Users\YOURNAME\AppData\Local\Packages\CanonicalGroupLimited...\LocalState\ext4.vhdx

These disks are "dynamically expanding" — they grow automatically as you use space inside the distro, but Windows never shrinks them back down on its own, even after you delete files from inside Linux. The freed space becomes available to the distro again, but not back to your Windows C: drive, until you compact the file manually.

Step 1: Shut down WSL completely

wsl --shutdown

Confirm everything actually stopped:

wsl -l -v

Every distro listed should show Stopped.

Step 2: Find your distro's vhdx file

The exact path depends on which distro you're running. For most Linux distros installed from the Microsoft Store, it's under:

%LOCALAPPDATA%\Packages\<DistroFolderName>\LocalState\ext4.vhdx

(If you're specifically dealing with Docker Desktop's disk rather than a Linux distro, the process is nearly identical but the file lives in a different folder — %LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx.)

Step 3: Compact the disk

On Windows 10/11 Pro or Enterprise, open PowerShell as Administrator:

Optimize-VHD -Path "C:\path\to\ext4.vhdx" -Mode Full

On Windows 10/11 Home, the Hyper-V module isn't available by default, so use diskpart instead:

diskpart
select vdisk file="C:\path\to\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

Want to actually reclaim a large amount of space? Compacting only returns space Linux itself has already marked as free. If your distro's disk is genuinely full of unused packages, logs, or old Docker layers, clean those up from inside WSL first — then shut down and compact. Compacting an already-full disk won't do much.

Step 4: Restart

Just open a terminal into your distro again, or start Docker Desktop — WSL restarts itself automatically on first use.

Prevent it from growing unchecked

You can cap how much a distro's disk is allowed to grow by editing %USERPROFILE%\.wslconfig:

[wsl2]
memory=6GB
processors=4
swap=0

This limits memory and CPU rather than disk size directly, but keeping WSL's resource usage in check tends to slow down how fast the disk fills in the first place — most growth comes from Docker layers and package caches building up over time.

I'm exploring building a small tool that finds this kind of thing automatically — WSL and Docker virtual disks, node_modules, build caches — across your whole drive instead of hunting for each one manually. Still early stage, but if you're curious: sweepdevv.netlify.app