Entwickler-Caches leeren, ohne Builds zu zerstören

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; 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 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 ihn leert.
• pnpm und yarn haben eigene Stores; pnpm store prune und yarn 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 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.

Karten zur Entdeckung, Paketmanager zur Bereinigung

Die Verstreuung ist das Entdeckungsproblem. Eine Treemap wie die Analyze-Ansicht von Mole 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.