Den npm-Cache auf dem Mac sicher leeren
AskClean-Team · Aktualisiert 2026-08-05
Ermittle den aktiven Cache mit npm config get cache, miss genau diesen Pfad und führe vor jeder Löschung npm cache verify aus. Nutze npm cache clean --force nur, wenn du den Platz wirklich brauchst und erneute Downloads in Kauf nimmst. node_modules, package.json und dein Lockfile gehören nicht zum Cache und bleiben unverändert.
npm-Cache, installierte Abhängigkeiten und Projektdateien trennen
Der npm-Cache speichert wiederverwendbare Downloads für mehrere Projekte und liegt auf macOS standardmäßig unter ~/.npm, kann aber anders konfiguriert sein. node_modules ist dagegen der installierte Abhängigkeitsbaum eines einzelnen Projekts. package.json und package-lock.json sind Projektzustand, kein Cache. Auch npm-shrinkwrap.json ist kein Cache; npm v12 liest sie im Projektstamm nicht mehr. Hat ein Altprojekt nur diese formatgleiche Sperrdatei, benenne sie vor einer npm-v12-Neuinstallation in package-lock.json um, ohne eine vorhandene package-lock.json zu überschreiben.
Aktiven Cache messen und zuerst verifizieren
Verlass dich nicht darauf, dass ein vorhandenes ~/.npm auch der aktive Cache ist. npm config get cache liefert den für diese Konfiguration verwendeten Pfad; miss genau ihn mit du und notiere den freien Speicher. npm cache verify prüft Index und Inhalte, kontrolliert die Integrität und räumt nicht mehr benötigte Daten auf, ohne gültige Downloads pauschal zu verwerfen. Bei normaler Wartung reicht das oft aus. Bleibt ein nicht cachebezogener Installationsfehler bestehen, braucht er eine eigene Diagnose statt weiterer Cache-Löschungen.
- Führe npm --version und npm config get cache aus und bestätige, dass der ausgegebene Pfad ein Cache und kein Projektordner ist.
- Miss genau diesen Pfad mit du -sh und notiere den freien macOS-Speicher; lass package.json und Lockfiles unverändert.
- Stoppe laufende npm install-, npm ci-, npm exec- und Veröffentlichungsprozesse, führe npm cache verify aus und halte die Zusammenfassung sowie etwaige Fehler fest.
- Führe npm cache clean --force nur aus, wenn verify nicht genügt, der Platzgewinn relevant ist und alle benötigten Artefakte später wieder erreichbar sind.
- Führe npm cache verify erneut aus, miss denselben Pfad und teste ein repräsentatives Projekt mit seinem unveränderten Lockfile, Build und Tests.
Gib niemals einen ungeprüften Pfad an rm -rf weiter. Kombiniere Cache-Bereinigung außerdem nicht mit dem Löschen oder Neuerzeugen eines Lockfiles, sonst veränderst du zwei Ursachen zugleich und verlierst die Vergleichsbasis.
npm cache clean --force nur bewusst einsetzen
Führe npm cache clean --force nur aus, wenn der gemessene Cache groß genug ist, der Platz jetzt zählt und spätere Downloads möglich sind. Der Befehl leert den konfigurierten Cache, nicht node_modules oder Lockfiles. Danach können npm install und npm ci länger dauern oder offline scheitern; private Registries, Git-Hosts, Proxys und nicht mehr angebotene Pakete erhöhen die Wiederherstellungskosten. Setze force nicht dauerhaft in der npm-Konfiguration.
Ergebnis prüfen, ohne den Abhängigkeitsgraphen zu ändern
Ermittle nach der Bereinigung erneut den Cachepfad, miss denselben Ort und vergleiche den tatsächlich freien macOS-Speicher. Teste ein repräsentatives Projekt mit unverändertem package.json und Lockfile sowie dessen Build und Tests. Tritt der ursprüngliche Fehler erneut auf, lösche den Cache nicht wiederholt: ERESOLVE, fehlende Anmeldung, 404, Proxy- oder Zertifikatsfehler, inkompatible Node.js-Versionen, native Builds und Lifecycle-Skripte brauchen eine eigene Diagnose. AskClean erkennt standardmäßig ~/.npm; benutzerdefinierte Pfade prüfst du mit npm selbst.
Löschgrenzen und Wiederherstellungskosten
Finde und miss den tatsächlich verwendeten npm-Download-Cache, prüfe ihn zuerst und leere ihn nur bei gutem Grund, ohne node_modules oder Projektdateien anzutasten.
| Element oder Aktion | Prüfen unter oder mit | Folge |
|---|---|---|
| npm-Cache, installierte Abhängigkeiten und Projektdateien trennen | npm config get cache | Der npm-Cache speichert wiederverwendbare Downloads für mehrere Projekte und liegt auf macOS standardmäßig unter ~/.npm, kann aber anders konfiguriert sein. node_modules ist dagegen der installierte Abhängigkeitsbaum eines einzelnen Projekts. package.json und package-lock.json sind Projektzustand, kein Cache. Auch npm-shrinkwrap.json ist kein Cache; npm v12 liest sie im Projektstamm nicht mehr. Hat ein Altprojekt nur diese formatgleiche Sperrdatei, benenne sie vor einer npm-v12-Neuinstallation in package-lock.json um, ohne eine vorhandene package-lock.json zu überschreiben. |
| Aktiven Cache messen und zuerst verifizieren | npm cache verify | Verlass dich nicht darauf, dass ein vorhandenes ~/.npm auch der aktive Cache ist. npm config get cache liefert den für diese Konfiguration verwendeten Pfad; miss genau ihn mit du und notiere den freien Speicher. npm cache verify prüft Index und Inhalte, kontrolliert die Integrität und räumt nicht mehr benötigte Daten auf, ohne gültige Downloads pauschal zu verwerfen. Bei normaler Wartung reicht das oft aus. Bleibt ein nicht cachebezogener Installationsfehler bestehen, braucht er eine eigene Diagnose statt weiterer Cache-Löschungen. |
| npm cache clean --force nur bewusst einsetzen | npm cache clean --force | Führe npm cache clean --force nur aus, wenn der gemessene Cache groß genug ist, der Platz jetzt zählt und spätere Downloads möglich sind. Der Befehl leert den konfigurierten Cache, nicht node_modules oder Lockfiles. Danach können npm install und npm ci länger dauern oder offline scheitern; private Registries, Git-Hosts, Proxys und nicht mehr angebotene Pakete erhöhen die Wiederherstellungskosten. Setze force nicht dauerhaft in der npm-Konfiguration. |
| Ergebnis prüfen, ohne den Abhängigkeitsgraphen zu ändern | Installation + Offline-/Private-Registry-Prüfung | Ermittle nach der Bereinigung erneut den Cachepfad, miss denselben Ort und vergleiche den tatsächlich freien macOS-Speicher. Teste ein repräsentatives Projekt mit unverändertem package.json und Lockfile sowie dessen Build und Tests. Tritt der ursprüngliche Fehler erneut auf, lösche den Cache nicht wiederholt: ERESOLVE, fehlende Anmeldung, 404, Proxy- oder Zertifikatsfehler, inkompatible Node.js-Versionen, native Builds und Lifecycle-Skripte brauchen eine eigene Diagnose. AskClean erkennt standardmäßig ~/.npm; benutzerdefinierte Pfade prüfst du mit npm selbst. |
FAQ
Ist npm cache clean --force auf dem Mac sicher?
Für Quellcode und Projektdateien ja, wenn npm auf den richtigen Cache zeigt. Du verlierst jedoch wiederverwendbare Downloads; miss und verifiziere zuerst und rechne bei späteren Installationen mit Netzwerkzugriff.
Sollte ich npm cache verify oder npm cache clean zuerst ausführen?
Immer zuerst npm cache verify. Der Befehl prüft die Integrität und entfernt nicht benötigte Daten, während gültige Cache-Inhalte erhalten bleiben. clean --force ist nur für gemessenen Platzbedarf oder ein bestätigtes Cacheproblem gedacht.
Löscht das Leeren des npm-Caches package-lock.json?
Nein. package.json und package-lock.json sind Projektdateien. npm v12 ignoriert npm-shrinkwrap.json im Projektstamm. Hat ein Altprojekt nur diese Sperrdatei, benenne sie in package-lock.json um, ohne eine vorhandene Datei zu überschreiben; lösche oder ändere Lockfiles nicht als Teil der Cache-Bereinigung.
Quellen