The node_modules problem, and how much you can actually delete

Why it gets so big

The JavaScript ecosystem favours small, single-purpose packages, and those packages depend on other packages, which depend on still more. A modest web app can pull in hundreds or thousands of them. That alone would be manageable if there were one copy. The real multiplier is that, with the traditional npm and Yarn Classic layout, every project gets its own complete copy.

The pnpm team put the cost in one sentence: "if you have 100 projects using a dependency, you will have 100 copies of that dependency saved on disk." A single modern app's node_modules commonly runs 200 to 500 MB; ten or twenty projects routinely add up to somewhere between 5 and 30 GB. Developers regularly report freeing 15 GB or more just by sweeping up stale ones.

The key distinction: project folders vs shared caches

There are two separate things people lump together as "npm junk," and they behave very differently.

The per-project node_modules folders are where the real space is, and they are the safest to delete, because they contain nothing you authored and are rebuilt by a single command.

Clearing node_modules safely

For one project, it is trivial: delete the folder, and reinstall when you next work on it.

# one project
$ rm -rf node_modules
$ npm install    # or pnpm install, or yarn, when you return to it

To see what is out there across your whole drive, find every node_modules and measure it. The -prune keeps find from descending into them, which is both faster and gives one total per project:

# list every node_modules with its size, largest first
$ find ~ -name node_modules -type d -prune -exec du -sh {} + 2>/dev/null | sort -rh | head -30

The shared caches

After the project folders, the global caches are a smaller, second helping. The npm cache is designed to be disposable. npm's own docs say it is "self-healing and resistant to data corruption," and that clearing it "should never be necessary except to reclaim disk space," which is exactly our reason. That is why the command needs a --force.

# npm: confirm the path, then clear (safe, re-downloads on demand)
$ npm config get cache
$ npm cache clean --force

# pnpm: remove packages no project references anymore
$ pnpm store path
$ pnpm store prune

# yarn: find the real cache dir for your version, then clean
$ yarn cache dir
$ yarn cache clean

The structural fix: pnpm

If the duplication really bothers you, the durable answer is to change how packages are stored. pnpm keeps one content-addressable copy of each package version in a global store and hard-links it into each project's node_modules. Switch several projects to pnpm and they share one physical copy of every shared dependency, which can cut total usage dramatically. One caveat: the store and your projects must be on the same filesystem, because hard links cannot cross one.

A sensible routine

1. Run the find command to list every node_modules by size.
2. Delete the folders in projects you have not worked on for a few months.
3. Run npm cache clean --force and pnpm store prune for a bit more.
4. Reinstall on demand the next time you open an old project.
5. Consider moving long-lived projects to pnpm to stop the duplication at the source.

Sources

• pnpm — motivation and store documentation (per-project duplication; shared hard-linked store; store prune).
• npm — cache documentation (self-healing cache; npm cache clean --force).
• Yarn — cache documentation for Classic and Berry (yarn cache dir, yarn cache clean).
• Developer write-ups on reclaiming space from stale node_modules (sizes are commonly reported, not official averages).