Überall node_modules: So findest du sie, räumst sie auf und holst sie zurück

Ein node_modules-Ordner enthält die installierten Abhängigkeiten eines JavaScript- oder TypeScript-Projekts und ist typischerweise einige Hundert Megabyte groß. Bei Dutzenden alter Projekte kommen so schnell mehrere Dutzend Gigabyte zusammen. Du kannst sie gefahrlos löschen, solange du package.json und das Lockfile behältst: Dein Paketmanager installiert dieselben Versionen neu, wenn du zum Projekt zurückkehrst.

Jeden node_modules-Ordner samt Größe finden

Dieser Befehl durchsucht deinen Benutzerordner, überspringt ~/Library und den Papierkorb und gibt jeden node_modules-Ordner mit seiner Größe aus, die größten zuletzt:

find ~ \( -path "$HOME/Library" -o -path "$HOME/.Trash" \) -prune -o -type d -name node_modules -prune -print0 2>/dev/null | xargs -0 du -sh 2>/dev/null | sort -h

So funktioniert er: Das erste -prune überspringt die beiden ausgeschlossenen Ordner, -type d -name node_modules findet die gesuchten Ordner, und das zweite -prune verhindert, dass find in sie absteigt. Verschachtelte node_modules werden also nur einmal gezählt, innerhalb ihres übergeordneten Ordners. du -sh misst jeden Ordner, und sort -h sortiert die Liste. Der Befehl liest nur. Bei einem großen Benutzerordner kann er ein paar Minuten dauern, und das Terminal fragt eventuell nach Zugriff auf „Dokumente“, „Schreibtisch“ oder „Downloads“.

Ignoriere Treffer in Tool-Ordnern wie ~/.nvm, ~/.vscode oder ~/.cursor. Sie gehören zu installierten Tools und Editor-Erweiterungen, nicht zu deinen Projekten.

Nutzen deine Projekte pnpm, sind die angezeigten Größen höher als das, was du tatsächlich zurückbekommst. Warum, erfährst du weiter unten.

Die nicht benötigten löschen

Öffne vor dem Löschen den Projektordner und prüfe, ob er ein Lockfile enthält: package-lock.json (npm), pnpm-lock.yaml (pnpm), yarn.lock (Yarn) oder bun.lock / bun.lockb (Bun). Behalte es, ebenso wie package.json.

Am sichersten löschst du, indem du node_modules im Finder in den Papierkorb ziehst. Bis du den Papierkorb leerst, kannst du es dir noch anders überlegen. Bei vielen kleinen Dateien dauert das Verschieben in den Papierkorb einen Moment.

Im Terminal, innerhalb eines Projektordners:

cd ~/Projects/old-app
rm -rf node_modules

rm -rf löscht endgültig, ohne Papierkorb. Prüfe vorher mit pwd, in welchem Ordner du bist, und führe den Befehl nie mit einem Platzhalter oder einer leeren Variablen aus.

npkill: eine interaktive Alternative

npkill listet node_modules-Ordner mit ihrer Größe auf und lässt dich einen nach dem anderen per Tastendruck löschen:

npx npkill -d ~/Projects

-d legt fest, wo die Suche beginnt; ohne die Option startet npkill im aktuellen Ordner. Navigiere mit den Pfeiltasten und drücke die Leertaste oder Entf, um den ausgewählten Ordner zu löschen. npkill löscht sofort, ohne Papierkorb. Ordner, die Apps zum Ausführen brauchen, markiert es mit ⚠️ – die solltest du in Ruhe lassen. Mit --dry-run simulierst du das Löschen, wenn du es erst ausprobieren willst.

Neu installieren, wenn du zu einem Projekt zurückkehrst

Nutze den Befehl, der genau das installiert, was im Lockfile steht:

npm ci setzt ein Lockfile voraus, entfernt zuerst ein vorhandenes node_modules und ändert weder package.json noch das Lockfile. Ein einfaches npm install funktioniert auch, kann aber das Lockfile aktualisieren.

Weitere Ordner, die sich selbst neu erstellen

Frameworks und Build-Tools legen Caches und Ausgaben neben node_modules ab. In Projekten, die gerade nicht laufen, kannst du sie gefahrlos löschen; der nächste Build oder Dev-Server erstellt sie neu.

dist und build enthalten meist ebenfalls Build-Ausgaben, aber die Namen sind allgemein. Manche Projekte versionieren dort Dateien oder nutzen die Ordner für etwas anderes. Sieh also hinein, bevor du sie löschst.

So listest du die Framework-Caches in einem Projektordner auf:

find ~/Projects -type d \( -name .next -o -name .nuxt -o -name .svelte-kit -o -name .turbo -o -name .parcel-cache \) -prune -print0 | xargs -0 du -sh | sort -h

Die globalen Paket-Caches leeren

Jeder Paketmanager hat außerdem einen Download-Cache, den alle Projekte teilen. Ihn zu leeren, ist endgültig, aber harmlos: Pakete werden bei Bedarf erneut geladen.

npm cache clean --force
pnpm store prune
yarn cache clean
bun pm cache rm

• npm legt seinen Cache in ~/.npm/_cacache ab. Die Dokumentation zu npm cache erklärt, warum clean ein --force braucht, und weist darauf hin, dass npm cache verify aufräumt, ohne alles zu leeren. Über npx geladene Pakete liegen in ~/.npm/_npx.
• pnpm hält seinen Store unter macOS in ~/Library/pnpm/store (pnpm store path zeigt deinen). pnpm store prune entfernt nur Pakete, auf die kein Projekt verweist, und die Dokumentation von pnpm empfiehlt, den Befehl gelegentlich statt ständig auszuführen.
• Yarn Classic cacht in ~/Library/Caches/Yarn. Bei Yarn Berry leert yarn cache clean --mirror den globalen Cache in ~/.yarn/berry/cache.
• Bun cacht in ~/.bun/install/cache; bun pm cache rm leert ihn.

Auch alte, mit nvm installierte Node.js-Versionen summieren sich in ~/.nvm/versions/node; nvm uninstall <version> entfernt eine, die du nicht mehr brauchst.

Warum pnpm weniger freigibt, als der Befehl du anzeigt

npm und Yarn Classic kopieren jedes Paket in das node_modules jedes Projekts. pnpm speichert jedes Paket einmal in einem inhaltsadressierten Store und verlinkt seine Dateien in jedes Projekt, das es nutzt. Unter macOS versucht pnpms Standardeinstellung packageImportMethod zuerst APFS-Klone, dann harte Links.

So oder so werden die Bytes geteilt. du zählt trotzdem in jedem Projekt die volle Größe. Das Löschen des node_modules eines pnpm-Projekts gibt daher meist viel weniger frei, als angezeigt wurde. Der Platz kommt zurück, wenn pnpm store prune Pakete entfernt, die kein verbliebenes Projekt mehr nutzt. Damit das funktioniert, muss der Store auf demselben Laufwerk liegen wie das Projekt; Projekte auf einem externen Laufwerk bekommen dort einen eigenen Store.

So hilft MoreRoom

Die Gratisversion von MoreRoom findet node_modules-Ordner in Projekten, die ein Lockfile haben und seit 30 Tagen nicht angefasst wurden, dazu Framework-Caches wie .next und .turbo, und markiert sie mit „Sicher entfernbar“. ~/Library und Tool-Ordner wie ~/.nvm und ~/.vscode überspringt sie. Du legst Objekte einzeln in den Papierkorb, mit Widerrufen. Für den npm-Cache und den pnpm-Store führt MoreRoom npm cache clean --force und pnpm store prune aus; diese Befehle sind endgültig und entsprechend gekennzeichnet.

MoreRoom Pro ergänzt den Projekt-Ruhezustand: Inaktive Projekte verlieren Ordner, die sich neu erstellen lassen, etwa node_modules und Build-Ausgaben, und wachen mit einem Klick wieder auf, wenn du zurückkehrst. Pro enthält außerdem den Sammler und den Zielmodus.