node_modules auf dem Mac löschen, ohne dein Projekt zu verlieren
AskClean-Team · Aktualisiert 2026-08-05
Du kannst node_modules löschen, wenn package.json, das richtige Lockfile und alle benötigten Abhängigkeiten weiterhin verfügbar sind. Miss den Speicherbedarf zuerst für jedes Projekt, stoppe laufende Prozesse und verschiebe nur den geprüften Abhängigkeitsordner in den Papierkorb. Installiere danach mit demselben Paketmanager neu und leere den Papierkorb erst, wenn Build, Tests und App wieder funktionieren.
node_modules vom eigentlichen Projekt trennen
node_modules enthält den installierten Abhängigkeitsbaum eines Projekts und ist unter passenden Bedingungen neu erzeugbar. Nach dem Löschen kann das Projekt bis zur vollständigen Neuinstallation weder laufen noch bauen. package.json, Lockfiles, Quellcode, Konfiguration, Patches, Workspace-Dateien und Git-Verlauf sind die Bauanleitung und dürfen nicht weg. Auch der gemeinsam genutzte npm-Download-Cache unter ~/.npm ist eine eigene Speicherkategorie.
Prüfen, ob sich die Abhängigkeiten wirklich neu erzeugen lassen
Ein Lockfile macht die Installation berechenbarer, ist aber kein Paket-Backup. Prüfe den vorgesehenen Paketmanager und seine Version, private Registry-Zugänge, VPN, Abhängigkeiten aus Git oder über file:, lokale Workspaces, externe Downloads sowie native Toolchains. npm v12 liest eine npm-shrinkwrap.json im Projektstamm nicht mehr. Hat ein Altprojekt nur diese formatgleiche Sperrdatei, benenne sie vor der Nutzung von npm v12 in package-lock.json um; überschreibe dabei niemals eine bereits vorhandene package-lock.json, sondern kläre Abweichungen als eigene, geprüfte Änderung. Änderungen, die nur in node_modules liegen, gehen beim Löschen verloren.
- Führe im Projektstamm pwd und du -sh ./node_modules aus und notiere zusätzlich den freien macOS-Speicher.
- Prüfe package.json, das richtige Lockfile, die Workspace-Konfiguration und lokale Änderungen mit git status. Hat ein Altprojekt nur npm-shrinkwrap.json, benenne sie vor der Nutzung von npm v12 in package-lock.json um, ohne eine vorhandene Datei zu überschreiben.
- Bestätige den Zugriff auf private Registries, Abhängigkeiten aus Git oder über file:, lokale Pakete, externe Downloads und Build-Werkzeuge und stoppe alle Prozesse, die node_modules verwenden.
- Verschiebe nur den geprüften node_modules-Ordner in den Papierkorb und installiere aus dem richtigen Repository-Stamm mit dem festgelegten Paketmanager und Lockfile neu.
- Führe Build, Tests, Lint-Prüfungen und App-Start aus, miss den Speicher erneut und leere erst danach den Papierkorb.
Nutze node_modules nie als einzige Kopie eines Pakets oder einer manuellen Korrektur. Ist eine exakte Abhängigkeit nicht mehr erreichbar und nirgendwo archiviert, kann das Löschen ein altes Projekt unbrauchbar machen.
Genau einen geprüften Abhängigkeitsordner entfernen
Verschiebe im bestätigten Projekt nur node_modules in den Finder-Papierkorb, niemals das übergeordnete Repository. rm -rf ./node_modules umgeht den Papierkorb und ist nicht rückgängig zu machen; prüfe davor mit pwd noch einmal den Projektstamm. Nutze dort npm ci, wenn package-lock.json maßgeblich ist, oder den vom Repository vorgegebenen Frozen-Lockfile-Ablauf für pnpm, Yarn oder Bun. Behandle ein Monorepo ausgehend vom Lockfile im Repository-Stamm als ein zusammenhängendes Abhängigkeitssystem.
Neuinstallation und Projekt vollständig verifizieren
Eine erfolgreiche Installation allein beweist noch nicht, dass das Projekt wiederhergestellt ist. Führe die dokumentierten Builds, Tests, Lint-Prüfungen und Startabläufe aus; native Add-ons und Lifecycle-Skripte können nach einem Toolchain-Wechsel trotzdem scheitern. Die Wiederherstellung kostet Downloads, Entpacken, Verlinken und gegebenenfalls Kompilieren. Schlägt sie fehl, stelle den Ordner aus dem Papierkorb wieder her und prüfe Zugriffsrechte, Netzwerk, Versionen und Lockfile, bevor du weitere Projekte bereinigst.
Löschgrenzen und Wiederherstellungskosten
Finde große node_modules-Ordner, schütze Quellcode und Lockfile, entferne Abhängigkeiten projektweise und installiere sie mit npm, pnpm, Yarn oder Bun sicher neu.
| Element oder Aktion | Prüfen unter oder mit | Folge |
|---|---|---|
| node_modules vom eigentlichen Projekt trennen | <Projekt>/node_modules | node_modules enthält den installierten Abhängigkeitsbaum eines Projekts und ist unter passenden Bedingungen neu erzeugbar. Nach dem Löschen kann das Projekt bis zur vollständigen Neuinstallation weder laufen noch bauen. package.json, Lockfiles, Quellcode, Konfiguration, Patches, Workspace-Dateien und Git-Verlauf sind die Bauanleitung und dürfen nicht weg. Auch der gemeinsam genutzte npm-Download-Cache unter ~/.npm ist eine eigene Speicherkategorie. |
| Prüfen, ob sich die Abhängigkeiten wirklich neu erzeugen lassen | package.json + Lockfile + Workspace-Konfiguration | Ein Lockfile macht die Installation berechenbarer, ist aber kein Paket-Backup. Prüfe den vorgesehenen Paketmanager und seine Version, private Registry-Zugänge, VPN, Abhängigkeiten aus Git oder über file:, lokale Workspaces, externe Downloads sowie native Toolchains. npm v12 liest eine npm-shrinkwrap.json im Projektstamm nicht mehr. Hat ein Altprojekt nur diese formatgleiche Sperrdatei, benenne sie vor der Nutzung von npm v12 in package-lock.json um; überschreibe dabei niemals eine bereits vorhandene package-lock.json, sondern kläre Abweichungen als eigene, geprüfte Änderung. Änderungen, die nur in node_modules liegen, gehen beim Löschen verloren. |
| Genau einen geprüften Abhängigkeitsordner entfernen | Papierkorb / Neuinstallation mit Paketmanager | Verschiebe im bestätigten Projekt nur node_modules in den Finder-Papierkorb, niemals das übergeordnete Repository. rm -rf ./node_modules umgeht den Papierkorb und ist nicht rückgängig zu machen; prüfe davor mit pwd noch einmal den Projektstamm. Nutze dort npm ci, wenn package-lock.json maßgeblich ist, oder den vom Repository vorgegebenen Frozen-Lockfile-Ablauf für pnpm, Yarn oder Bun. Behandle ein Monorepo ausgehend vom Lockfile im Repository-Stamm als ein zusammenhängendes Abhängigkeitssystem. |
| Neuinstallation und Projekt vollständig verifizieren | Build + Tests + App-Start | Eine erfolgreiche Installation allein beweist noch nicht, dass das Projekt wiederhergestellt ist. Führe die dokumentierten Builds, Tests, Lint-Prüfungen und Startabläufe aus; native Add-ons und Lifecycle-Skripte können nach einem Toolchain-Wechsel trotzdem scheitern. Die Wiederherstellung kostet Downloads, Entpacken, Verlinken und gegebenenfalls Kompilieren. Schlägt sie fehl, stelle den Ordner aus dem Papierkorb wieder her und prüfe Zugriffsrechte, Netzwerk, Versionen und Lockfile, bevor du weitere Projekte bereinigst. |
FAQ
Ist es sicher, node_modules auf dem Mac zu löschen?
Meist ja, wenn package.json, das korrekte Lockfile, Workspace-Dateien, Quellcode und alle Bezugsquellen erhalten sind. Das Projekt bleibt jedoch außer Betrieb, bis Neuinstallation und Prüfungen erfolgreich abgeschlossen sind.
Sollte ich package-lock.json zusammen mit node_modules löschen?
Nein. package-lock.json ist die Eingabe für eine reproduzierbare npm-Installation. npm v12 liest npm-shrinkwrap.json im Projektstamm nicht mehr. Liegt in einem Altprojekt nur diese formatgleiche Datei vor, benenne sie in package-lock.json um; überschreibe dabei keine bereits vorhandene Sperrdatei.
Sind node_modules und der npm-Cache dasselbe?
Nein. node_modules ist der installierte Abhängigkeitsbaum eines Projekts. Der gemeinsam genutzte npm-Cache liegt standardmäßig unter ~/.npm. Das Löschen der einen Kategorie entfernt die andere nicht.
Quellen