npm- und pnpm-Caches: wo in AppData die Gigabyte verschwinden

Zwei Werkzeuge, zwei Cache-Modelle

npm pflegt einen inhaltsadressierten Cache unter %LOCALAPPDATA%\npm-cache: jedes jemals geladene Tarball-Archiv, dazu Logs und der _npx-Cache für Einmal-Downloads von Paketen. Keines davon braucht es, damit installierte Projekte weiterlaufen — der Cache existiert nur, um künftige Installationen schneller und offlinefähig zu machen. pnpm löst das anders: Ein einziger Store (in neueren Versionen unter %LOCALAPPDATA%\pnpm\store) hält die echten Dateien, und jeder node_modules-Ordner in jedem Projekt besteht aus Hardlinks dorthin. Deshalb blähen pnpm-Projekte den Platz nicht npm-artig auf — und deshalb wächst der Store selbst grenzenlos: Jede neue Paketversion bleibt dort dauerhaft liegen, bis man aufräumt.

Daher die vertraute Überraschung: Sie löschen ein altes Projekt, und der Platz kommt nicht zurück, weil die Hardlinks im Store die Daten am Leben halten. Der Kandidat ist der Store, nicht die Projektordner.

Die Aufräum-Kommandos, die sich lohnen

Alles hier ist per Definition sicher — Caches sind Caches, die Werkzeuge bauen sie bei Bedarf wieder auf:

• npm cache clean --force — räumt den kompletten npm-Cache leer; die nächsten Installationen laden neu, was nötig ist
• npm cache verify — die sanfte Variante: Garbage Collection und Integritätsprüfung statt Rundumschlag
• pnpm store prune — entfernt Pakete aus dem Store, auf die kein Projekt mehr verlinkt
• %LOCALAPPDATA%\npm-cache\_npx löschen — Wegwerf-Caches aus npx-Läufen, immer gefahrlos
• npm config set cache D:\dev\npm-cache — verlagert den Cache dauerhaft von der SSD auf ein Datenlaufwerk
• Erst messen: ein Größen-Scan von AppData schlägt blindes Löschen — npm-cache und der pnpm-Store sind die üblichen Verdächtigen

Die NTFS-Hardlink-Falle

Und jetzt der Teil, der alle verwirrt: Auf NTFS werden die Daten einer Datei erst freigegeben, wenn der letzte Hardlink auf sie verschwindet. Den pnpm-Store löschen, nachdem Sie node_modules leergeräumt haben — der Platz kommt wie erwartet zurück. Den Store löschen, während Projekte noch auf seine Dateien verlinken — bringt nichts: Die Bytes bleiben solange auf der Platte, wie node_modules existiert, und der Explorer zeigt Store-Einträge an, die faktisch leere Hüllen sind. Die Reihenfolge zählt: erst die Projekte (oder deren node_modules) entfernen, dann pnpm store prune laufen lassen. CI-Runner und Rechner, die ständig durch Repositories rauschen, ziehen aus einem monatlichen Durchlauf den größten Nutzen; auf dem Ein-Projekt-Laptop lohnt der Aufwand selten.

Fragen und Antworten

Weiterlesen