Is it safe to delete node_modules?

Yes — as long as the lockfile is intact and you can reinstall. Here is what actually breaks, what does not, and how to check before you delete.

Updated 2026-09-20

Short answer: yes. node_modules is a build product. Nothing in it is authored by you, and every file in it is described by your lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock or bun.lock). Delete it, run your install command, and you get the same tree back, byte for byte, because that is precisely what a lockfile is for.

The long answer is the interesting one, because "the lockfile describes it" is a claim that is sometimes false, and the cases where it is false are exactly the cases where deleting hurts.

What you are actually deleting

A node_modules directory holds three kinds of thing:

• Downloaded packages. Fetched from a registry, addressed by a hash the lockfile records. These come back exactly.
• Build output from install scripts. Native modules compiled by node-gyp, binaries downloaded by a postinstall step, prebuilt artefacts unpacked into place. These come back if the machine can still build or fetch them — which needs a compiler, or network access to whatever the postinstall step reaches for.
• Whatever you edited by hand. Which is nothing, unless you have been debugging a dependency by editing it in place. If you have, that work is not in any lockfile and it is gone the moment you delete.

So the honest rule is not "node_modules is always safe to delete". It is: node_modules is safe to delete when the lockfile can rebuild it and you have not modified it.

Check before you delete

Every package manager has a command that answers the question without installing anything. Run the one that matches your lockfile:

npm ci --dry-run --ignore-scripts
          pnpm install --lockfile-only
          yarn install --immutable --immutable-cache
          bun install --frozen-lockfile --dry-run

If it exits zero, the lockfile is coherent with package.json and the registry can serve every version it names. If it fails, do not delete — a failure here means reinstalling would not give you what you have. The two failures worth knowing:

• A package in node_modules is missing from the lockfile. Usually somebody ran npm install <pkg> and committed package.json without the lockfile. Deleting loses that package until somebody notices.
• A version in the lockfile no longer exists. Unpublished, or a private registry that has rotated. Your installed copy is now the only copy you have.

What deleting costs you

Time, and only time — but the amount varies more than people expect. A warm cache and a pnpm store make reinstalling a matter of hardlinking, and it finishes in seconds. A cold cache on a slow connection with three native modules to compile is minutes. This is why clearing your package manager cache and deleting node_modules are not the same decision and should not be made together: the cache is the thing that makes the delete cheap.

The monorepo footnote

In a workspace, node_modules exists at the root and inside packages, and the nested ones are often symlinks into the root. Deleting a symlink is harmless; deleting through one is how people lose the root store by accident. If you are writing your own cleanup, use a tool that refuses to follow symlinks rather than one that resolves them.

Doing it across every project at once

One project is a rm -rf. Thirty projects is a script, and a script that does not run the verification above is a script that will eventually delete something that does not come back.

That is the job dev-prune does: it walks your Git repositories, runs the matching dry-run for whichever lockfile it finds, and deletes only after that command exits zero. When it does not, it says which package failed and moves on rather than deleting anyway. Deleting node_modules from every project at once covers that case in full.