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

> Finde jeden node_modules-Ordner auf deinem Mac samt Größe, lösche die unnötigen, installiere aus dem Lockfile neu und leere die Caches der Paketmanager.

- URL: https://moreroom.app/de/learn/node-modules-cleanup
- Published: 2026-10-17
- Updated: 2026-10-17
- Publisher: MoreRoom (Yando Pte. Ltd.) — https://moreroom.app

## TL;DR

- node_modules zu löschen ist gefahrlos, solange du package.json und das Lockfile behältst; npm ci oder pnpm install holt exakt dieselben Versionen zurück.
- find mit -prune listet jeden node_modules-Ordner in deinem Benutzerordner samt Größe auf, ohne in verschachtelte Ordner abzusteigen.
- Mit npx npkill durchsuchst du node_modules-Ordner und löschst sie interaktiv – allerdings sofort, ohne Papierkorb.
- Bei pnpm sind die Dateien in node_modules Klone oder harte Links eines gemeinsamen Stores. Ihr Löschen bringt wenig, bis du pnpm store prune ausführst.
- Build-Ordner wie .next, .turbo, .nuxt, .svelte-kit und .parcel-cache werden automatisch neu erstellt und lassen sich ebenfalls gefahrlos entfernen.

Ein [node_modules](https://moreroom.app/glossary#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:

```sh
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:

```sh
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](https://github.com/voidcosmos/npkill) listet `node_modules`-Ordner mit ihrer Größe auf und lässt dich einen nach dem anderen per Tastendruck löschen:

```sh
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:

| Paketmanager | Lockfile | Neu installieren |
|---|---|---|
| npm | `package-lock.json` | `npm ci` |
| pnpm | `pnpm-lock.yaml` | `pnpm install --frozen-lockfile` |
| Yarn (Berry) | `yarn.lock` | `yarn install --immutable` |
| Yarn Classic | `yarn.lock` | `yarn install --frozen-lockfile` |
| Bun | `bun.lock` | `bun install --frozen-lockfile` |

[`npm ci`](https://docs.npmjs.com/cli/v11/commands/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.

| Ordner | Erstellt von |
|---|---|
| `.next` | Next.js |
| `.nuxt` | Nuxt |
| `.svelte-kit` | SvelteKit |
| `.turbo` | Turborepo |
| `.parcel-cache` | Parcel |
| `.angular` | Angular CLI |

`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:

```sh
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.

```sh
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](https://docs.npmjs.com/cli/v11/commands/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`](https://pnpm.io/cli/store) 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](https://pnpm.io/motivation) und verlinkt seine Dateien in jedes Projekt, das es nutzt. Unter macOS versucht pnpms Standardeinstellung [`packageImportMethod`](https://pnpm.io/settings/node-modules) zuerst APFS-Klone, dann [harte Links](https://moreroom.app/glossary#hard-link).

![npm kopiert Pakete in jedes Projekt, pnpm teilt einen einzigen Store über Klone oder harte Links](https://moreroom.app/learn/img/node-modules-cleanup-pnpm-store.svg)

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.

## FAQ

### Kann ich node_modules gefahrlos löschen?

Ja. Der Ordner enthält nur installierte Abhängigkeiten, die dein Paketmanager aus package.json und dem Lockfile erneut installieren kann. Lösche ihn nur bei Projekten, die gerade nicht laufen, und behalte das Lockfile.

### Sollte ich package-lock.json auch löschen?

Nein. Das Lockfile hält die genauen Versionen fest, die funktioniert haben. Behalte es, damit npm ci, pnpm install oder yarn install später dasselbe node_modules wiederherstellen können.

### Warum gibt das Löschen von node_modules in einem pnpm-Projekt so wenig Platz frei?

pnpm hält jedes Paket einmal in einem gemeinsamen Store und klont die Dateien in jedes Projekt oder verlinkt sie dorthin per harten Link. Löschst du das node_modules eines Projekts, verschwinden nur die Links; pnpm store prune löscht danach die Pakete, die kein Projekt mehr nutzt.

### Ist npm cache clean --force sicher?

Ja. Es leert den Download-Cache von npm in ~/.npm/_cacache, und npm lädt Pakete bei Bedarf erneut. Die Dokumentation von npm weist darauf hin, dass das Leeren des Caches nur sinnvoll ist, um Speicherplatz freizugeben.

### Legt npkill Ordner in den Papierkorb?

Nein. npkill löscht die ausgewählten Ordner sofort. Probiere es mit der Option --dry-run aus und nutze den Finder, wenn du den Papierkorb als Sicherheitsnetz willst.