node_modules Warfare: Reclaiming Gigabytes From Dead Side Projects

Why one folder can outweigh your OS

npm installs every dependency into a local node_modules per project — no sharing and no deduplication between projects by default. A modest web app easily pulls 800 MB to 2 GB across a thousand packages, and the file count is the real killer: tens of thousands of tiny files that Windows Defender scans, backup tools crawl, and OneDrive — if your projects live in a synced folder — chokes on forever. It's also why installs take minutes on Windows compared to seconds on Linux: the per-file overhead of creating small files is brutal. Five abandoned experiments later, you are looking at 10–15 GB that nothing actively uses.

Delete without fear: the lockfile is your guarantee

The contract is simple: package.json says what you need, package-lock.json says exactly which versions you had, and node_modules is just the unpacked result of those two. Delete node_modules, run npm ci, and the identical tree comes back in a few minutes — that is not a recovery trick, it is the intended workflow. The only unforgivable mistake is deleting the lockfile, or letting a project rot without one committed. For finding the folders, npx npkill scans all your drives, lists every node_modules with size and last-modified date, and deletes the ones you mark; WizTree does the same job as a general disk map if you want the big picture.

• Delete node_modules — never package.json or the lockfile
• Reinstall with npm ci: it follows the lockfile exactly, unlike npm install
• Run npx npkill to find and kill node_modules across all drives
• Keep active projects out of OneDrive and Dropbox folders — file counts kill sync
• Dead project? Zip it without node_modules, then delete the folder
• Try pnpm for new projects: one global store, projects link into it

The caches behind the folder

Even with every node_modules gone, npm keeps a second hoard: the cache in %LOCALAPPDATA%\npm-cache, holding a copy of every package version you have ever installed — gigabytes that grow monotonically for years. npm cache verify cleans it up safely, and the same logic applies to pnpm store prune and yarn cache clean for their respective stores. The npm cache is worth keeping enabled: it is what makes reinstalling a project with an empty cache the slow path instead of the normal one. A periodic junk sweep with Kleaner PRO catches these developer caches alongside the usual temp files — useful when several tools have been quietly hoarding on the same machine.

Questions and Answers

Read next