Why Your Storage Keeps Filling Up With Duplicate node Files (And How to Fix It for Good)

If you build websites or apps — or use an AI tool like Claude to build them for you — and you have ever gone digging through your storage (on macOS via Storage → Documents → Large Files, on Windows via a tool like WinDirStat or Storage Sense, or on Linux via du/ncdu) only to find the same 100–130 MB file repeated five or six times, this article is for you.

The Problem

You will see a file named something like:

next-swc.darwin-arm64.node

(The exact name depends on your OS and chip — Windows might show next-swc.win32-x64-msvc.node, Linux next-swc.linux-x64-gnu.node, and so on. Same file, different platform build.)

...showing up again and again, each copy sitting in a different project folder, each one 100–130 MB. Six copies easily adds up to 600–700 MB of pure duplication — and it is not a one-off. Every new project you (or your AI assistant) creates adds another copy.

Why this happens:

Most JavaScript/web projects — especially ones built on the popular Next.js framework — depend on a compiled binary that helps the framework run fast. When you set up a new project, the standard package manager (npm) downloads this binary fresh and copies it into that project own private node_modules folder.

The problem is npm does not share this file between projects. Ten projects means ten separate downloads and ten separate copies sitting on your disk — even though the file is identical every time.

If you work across multiple projects (which is common if you are using AI tools to spin up different websites, dashboards, or prototypes), this duplication compounds fast and quietly eats your storage.

A common misconception worth clearing up: this download does not consume extra AI "tokens" or session usage — it is just your computer fetching a file from the internet, the same as it would with no AI involved. The real cost here is disk space and repeated download time, not AI usage.

The Solution

Quick fix (do this now)

For any project you are not actively using, you can safely delete its node_modules folder entirely. Nothing is lost — running npm install in that project again will rebuild it from scratch. This is usually the single biggest space recovery you can do in any JavaScript project folder.

The real, long-term fix: switch to pnpm

The permanent solution is to stop using plain npm for installing project dependencies and switch to pnpm — a drop-in alternative that solves this exact problem by design.

Instead of copying a full copy of every package into every project, pnpm keeps one shared copy of each package version in a central location on your disk, and each project simply links to it. Same functionality, same files available to every project — just no duplication.

How to switch:

1. Install pnpm once, globally:

   npm install -g pnpm

2. For any new project going forward, use:

   pnpm install

   instead of npm install.
3. For existing projects, delete the node_modules folder and run pnpm install in that project instead — it will rebuild using the shared cache.

Result: instead of six projects each storing their own 120 MB copy of the same file (720 MB total), you get one shared 120 MB copy that every project quietly links to.

The Takeaway

If you are managing several coding projects — particularly on a machine with limited storage — this single switch (from npm to pnpm) is a one-time, five-minute change that prevents an ongoing storage drain you would otherwise keep hitting project after project, no matter which operating system you are on.