Hygiene für den Entwickler-PC: npm, pip, Docker und der ganze Rest

Wohin eine Entwickler-Platte wirklich geht

Die vier großen Sammler überraschen niemanden, der einmal hingeschaut hat: Paket-Caches wachsen standardmäßig ohne Obergrenze, node_modules dupliziert den Abhängigkeitsbaum in jedem Projekt, Docker behält jeden je gezogenen oder gebauten Layer, und WSL2 verwahrt das komplette Linux-Dateisystem in einer virtuellen Platte, die bei Bedarf wächst und von sich aus nie schrumpft. Rechnen Sie IDE-Indizes, Build-Artefakte und drei SDK-Versionen nebeneinander dazu — eine zweijährige Maschine schleppt mühelos zig Gigabyte nachweislich totes Gewicht mit. Mysteriös ist daran nichts: Der Müll verteilt sich nur auf ein Dutzend Verzeichnisse, in die Sie nie hineinschauen.

• npm: %LOCALAPPDATA%\npm-cache — vollständige Kopien jeder Version jedes Pakets, das Sie je installiert haben
• pip: %LOCALAPPDATA%\pip\cache — Wheels von allem Möglichen, plus ~/.cache/pip innerhalb jeder WSL-Distribution
• Docker Desktop: dangling Images, gestoppte Container, Build-Cache und anonyme Volumes — docker system df zeigt die Summe, docker system prune holt sie zurück
• WSL2: die Distributions-Datei ext4.vhdx wächst mit jedem Build und gibt Platz nie von allein zurück
• Projekte: das node_modules eines aufgegebenen Repos wiegt einige hundert MB bis mehrere GB — der Wert steckt im Lockfile, der Ordner ist neu baubar
• IDEs: JetBrains-Cache- und Indexverzeichnisse, dazu die Ordner target/, build/, dist/, obj/ über alle Checkouts verstreut

Der Quartalsdurchgang, in der richtigen Reihenfolge

Messen Sie zuerst, damit die Stunde dorthin geht, wo die Masse liegt: ein Treemap-Werkzeug über das Benutzerprofil, docker system df für die Container-Seite, wsl --list --verbose für die Distributionen. Dann arbeiten Sie von sicher nach riskant: Caches werden bei Bedarf neu aufgebaut, also dürfen Sie sie bedenkenlos leeren — npm cache clean --force, pip cache purge und die Pendants in Gradle und cargo; als Nächstes kommen aufgegebene Projekte — Abhängigkeitsordner löschen, Lockfiles behalten, und sobald das Repo erwacht, stellt npm ci oder pip install -r alles in Minuten wieder her. Danach Docker: dangling Images und Build-Cache entsorgen, die getaggten Images behalten, die Sie wirklich starten. Zuletzt die virtuelle WSL2-Platte, denn Löschungen innerhalb der Distribution verkleinern die Datei auf der Windows-Seite nicht: wsl --shutdown ausführen und die vhdx komprimieren — oder die Distribution exportieren und neu importieren, wenn sie wirklich monströs gewachsen ist.

Gewohnheiten, die die Platte flach halten

Hygiene ist als Gewohnheit billiger als als Rettungsaktion. Halten Sie Werkzeuge pro Projekt statt global, lassen Sie CI die Images ziehen statt sie lokal zu horten, und werfen Sie monatlich docker system prune an, bevor der Layer-Zoo ein Gedächtnis entwickelt. Verlegen Sie mehrstellige Gigabyte an Datensätzen auf eine zweite Platte und verlinken Sie sie — die Systemplatte hält dann nur noch das, was sich neu erzeugen lässt. Und behandeln Sie eine fast volle C:-Platte als Bau-Zwischenfall, nicht als Kosmetik: npm, Docker und die Compiler-Toolchain scheitern auf die erfindungsreichsten Arten, wenn der Scratch-Speicher ausgeht.

Fragen und Antworten

Weiterlesen