# Entwickler-Caches leeren, ohne Builds zu zerstören > Quellcode, Lockfiles, Registry-Zugang und einzigartige lokale Artefakte bewahren, bevor Package-Stores und Abhängigkeitsbäume ausgedünnt werden. Published: 2026-06-03 | Updated: 2026-08-08 Entwicklerspeicher ist über Paket-Downloads, Build-Ausgaben, SDKs, lokale Datenbanken und projektbezogene Dependency-Bäume verteilt. Manches lässt sich reproduzieren, manches hängt von einer Lockfile und einer Registry ab, die später verschwinden kann, und manches ist einzigartige lokale Daten. Eine sichere Bereinigung stellt fest, welche Art sie gefunden hat, statt anzunehmen, dass jeder Dot-Ordner Cache ist. ## Die globalen Caches nach Tool Jeder Paketmanager hält einen globalen Store, den Sie direkt messen können: ``` du -sh ~/.npm ~/.cargo ~/.cache/pip ~/Library/Caches/pip ~/.gradle 2>/dev/null | sort -h ``` Das sind Standardpfade, kein Versprechen. Fragen Sie das Tool nach seinem konfigurierten Pfad, wenn möglich, zum Beispiel `npm config get cache`, `python -m pip cache dir` und `pnpm store path`. - **npm** speichert Downloads standardmäßig in `~/.npm`. Beginnen Sie mit [`npm cache verify`](https://docs.npmjs.com/cli/commands/npm-cache); npm beschreibt seinen Cache als self-healing, daher ist `npm cache clean --force` vor allem für bewusste Speicherfreigabe oder Fehlersuche gedacht. - **Cargo** hält Registries und Git-Checkouts unter `~/.cargo`, aber das [Cargo home](https://doc.rust-lang.org/cargo/guide/cargo-home.html) kann auch installierte Binaries, Konfiguration, Paketdaten und Registry-Zugangsdaten enthalten. Aktuelles Cargo entfernt ungenutzte globale Cache-Einträge periodisch bei Build- und Fetch-Befehlen. Lassen Sie diese Richtlinie wirken, oder prüfen Sie die genauen Cache-Unterverzeichnisse. Entfernen Sie niemals ganz `~/.cargo`. - **pip** speichert Wheels und HTTP-Antworten standardmäßig in `~/Library/Caches/pip`. `python -m pip cache info` meldet den tatsächlichen Speicherort und die Größe, während [`python -m pip cache purge`](https://pip.pypa.io/en/stable/cli/pip_cache/) ihn leert. - **pnpm** und **yarn** haben eigene Stores; `pnpm store prune` und [`yarn cache clean`](https://yarnpkg.com/cli/cache/clean) bereinigen nicht referenzierte oder gecachte Pakete. Prüfen Sie die aktive Paketmanager-Version, weil Store-Layout und lokales versus globales Cache-Verhalten abweichen. - **Gradle** und **Maven** (`~/.gradle`, `~/.m2`) können auf Android- und JVM-Macs sehr groß werden. Gradle führt bereits eine [periodische Cache-Bereinigung](https://docs.gradle.org/current/userguide/directory_layout.html) durch; stoppen Sie die Daemons vor einer manuellen Prüfung. Ein Maven-Repository kann lokal gebaute oder private Artefakte enthalten, die sich nicht erneut herunterladen lassen. Prüfen Sie es daher, statt das gesamte Repository standardmäßig zu löschen. Die Kosten können ein großer Download, ein nativer Rebuild oder ein fehlgeschlagener historischer Build sein, wenn eine Registry-Version weg ist. Prüfen Sie Lockfile und Quelle jeder Dependency, bevor Sie einen Store als reproduzierbar bezeichnen. ## Das verstreute node_modules-Problem Die größere Überraschung ist meist nicht ein einzelner Cache, sondern die `node_modules`-Ordner, die über jedes JavaScript-Projekt verteilt sind, das Sie je berührt haben. Jeder ist in sich geschlossen und oft 200 bis 500 MB groß, sodass zehn alte Projekte mehrere Gigabyte verstecken können. Finden Sie sie und ihre Größen: ``` find ~/www ~/Projects -name node_modules -type d -prune -exec du -sh {} + 2>/dev/null ``` Ersetzen Sie die Beispiel-Wurzeln durch die Ordner, in denen Sie Projekte halten. `-prune` verhindert, dass `find` in einen gefundenen Dependency-Baum absteigt, und `-exec` behandelt Leerzeichen und ungewöhnliche Zeichen in Pfaden sicher. Ein Projekt kann seine Dependencies nur dann neu aufbauen, wenn Quelle, Lockfile, Paketmanager-Version, Registry-Zugang und die benötigte native Toolchain noch verfügbar sind. Bevorzugen Sie den lockfile-spezifischen Befehl, etwa `npm ci`, nachdem Sie diese Eingaben gesichert haben. ## Das sollten Sie nicht löschen Paket-Caches können ersetzbar sein, zwei Nachbarn sind es nicht. Projekt-**Quelle und Lockfiles** (`package.json`, `package-lock.json`, `Cargo.lock`) sind kein Cache, sie definieren den Build, also fegen Sie sie nie weg. Und ein globaler Store, den Sie aktiv nutzen, etwa ein über Projekte geteilter content-addressed pnpm-Store, wird zwar erneut herunterladen, eine Löschung mitten in der Installation kann ihn aber korrumpieren. Leeren Sie Caches daher, wenn gerade nichts baut. ## Unter der Haube: content-addressed Stores und warum node_modules die Ausnahme ist Viele Paketmanager nutzen content-addressed Stores, um wiederholte Downloads zu reduzieren. pnpm hält einen globalen Store jeder Paketversion und hard-linkt sie in das `node_modules` jedes Projekts, sodass zehn Projekte mit derselben Library eine einzige Kopie auf der Platte teilen. Cargo- und Go-Caches keyen heruntergeladene Inhalte ebenfalls nach Version oder Checksumme. Das schützt die Integrität, garantiert aber keine künftige Verfügbarkeit. Eine herkömmliche npm-Installation materialisiert pro Projekt einen Dependency-Baum, während pnpm Projekte an einen geteilten Store binden kann. Deshalb haben das Löschen eines einzelnen `node_modules`-Verzeichnisses und das Prunen eines geteilten Stores unterschiedliche Wirkung.
Links ein gemeinsamer globaler Store per Hard Link in mehrere Projekte; rechts dieselbe Bibliothek in jedes node_modules jedes Projekts kopiert und damit dupliziert
Ein geteilter content-addressed Store und ein materialisierter pro-Projekt-Dependency-Baum haben unterschiedliche Speicherkosten und unterschiedliche Bereinigungsgrenzen.
## Karten zur Entdeckung, Paketmanager zur Bereinigung Die Verstreuung ist das Entdeckungsproblem. Eine Treemap wie die Analyze-Ansicht von [Mole](https://mole.fit/) kann zeigen, welches Projekt oder welcher Store groß ist, aber der eigene Verify-, Prune- oder Clean-Befehl des Paketmanagers kennt Index und Referenzen. Nutzen Sie die Karte, um ein Ziel zu wählen, und das zuständige Tool, um es zu ändern. ## Eine sichere Reihenfolge Stoppen Sie Builds und Daemons, messen Sie ausgewählte Projektwurzeln, prüfen Sie die Stores der Paketmanager und bewahren Sie Quelle plus Lockfiles, bevor Sie einen Dependency-Baum entfernen. Nutzen Sie dokumentierte Prune-Befehle statt einen kompletten Dot-Ordner im Home-Verzeichnis zu löschen. Bauen Sie ein Projekt neu auf, bevor Sie den Papierkorb leeren. Ziel ist, reproduzierbare Ausgaben zu entfernen und die Informationen zu behalten, die zur Reproduktion nötig sind. --- Canonical HTML page: https://mole.fit/de/blog/how-to-clear-dev-caches-mac Blog index for agents: https://mole.fit/de/blog/llms.txt Site index for agents: https://mole.fit/llms.txt