node_modules, npm-Cache und SwiftPM: Platz schaffen ohne Chaos

Ein einzelnes JavaScript-Projekt wirkt harmlos. Zwanzig davon, jedes mit eigenem node_modules-Ordner, belegen schnell einen spürbaren Teil einer kleinen internen SSD. Dazu kommen der zentrale npm-Cache, bei pnpm ein eigener Paketspeicher und auf der Swift-Seite die Caches des Swift Package Managers. Das Gute daran: Vieles davon ist reproduzierbar. Das weniger Gute: Wer blind löscht, verliert Zeit, und wer blind verschiebt, riskiert kaputte Pfade.

Diese Seite ordnet die Paketdaten auf deinem Mac ein und vergleicht drei Wege zu mehr Platz: löschen und neu installieren, die Werkzeuge selbst umkonfigurieren oder ganze Projektordner auf eine externe SSD verlegen.

Wo die Daten liegen

Erst messen

Mit du -sh ~/.npm siehst du die Größe des npm-Caches. Mit du -sh ~/Projekte/*/node_modules bekommst du die node_modules-Ordner aller Projekte in ~/Projekte auf einen Blick, sofern sie direkt im jeweiligen Projektordner liegen. Monorepos mit mehreren verschachtelten node_modules erfasst dieser Befehl nur teilweise. Beide Befehle lesen nur und verändern nichts.

Aufschlussreich ist der Vergleich mit dem Alter der Projekte. Oft zeigt sich, dass ein großer Teil des Platzes auf Projekte entfällt, die seit Monaten ruhen. Für sie gilt ein anderer Weg als für das Projekt, an dem du täglich arbeitest.

Weg 1: Löschen und bei Bedarf neu installieren

node_modules ist kein Arbeitsergebnis, sondern ein reproduzierbarer Zustand. Liegen package.json und das Lockfile im Projekt, stellt npm ci die Abhängigkeiten exakt nach Lockfile wieder her; einen vorhandenen node_modules-Ordner entfernt der Befehl dabei vorher. Bei Projekten, die du monatelang nicht anfasst, ist Löschen deshalb oft die einfachste Lösung.

Bedenke die Nebenwirkungen: Die Neuinstallation braucht eine Internetverbindung und Zeit, native Module werden eventuell neu kompiliert, und für private Registries brauchst du weiterhin Zugang. Ohne committetes Lockfile bekommst du womöglich andere Versionen als vorher. Prüfe deshalb vor dem Löschen, ob das Lockfile im Repository liegt.

Für den npm-Cache gibt es npm cache verify. Der Befehl prüft den Cache und räumt nicht mehr benötigte Daten ab. npm cache clean --force leert ihn vollständig, danach lädt npm alles bei Bedarf neu. Auf der Swift-Seite leert swift package purge-cache den SwiftPM-Cache, und in Xcode setzt „File“ → „Packages“ → „Reset Package Caches“ die Paket-Caches eines Projekts zurück.

Weg 2: Die Werkzeuge selbst umkonfigurieren

Manche Caches kannst du über die Werkzeuge an einen anderen Ort legen. Für npm setzt npm config set cache /Volumes/Arbeit-SSD/npm-cache einen neuen Cache-Ort auf der SSD. pnpm bietet dafür die Einstellung store-dir. Bei pnpm gibt es eine wichtige Einschränkung: Das Werkzeug verknüpft Pakete aus seinem Speicher per Hardlink oder als Klon in die Projekte, und beides funktioniert nur innerhalb eines Laufwerks. Liegt der Speicher auf der SSD und das Projekt auf der internen SSD, wird kopiert statt verknüpft, und du sparst weniger als erwartet.

Der Vorteil dieses Wegs: Er ist offiziell vorgesehen, und das Werkzeug weiß selbst, wo seine Daten liegen. Der Nachteil: Du musst jedes Werkzeug einzeln einstellen, und die node_modules-Ordner in den Projekten bleiben davon unberührt.

Weg 3: Ganze Projektordner auslagern

Oft ist es sinnvoller, nicht einzelne node_modules-Ordner zu verlinken, sondern den gesamten Projektordner auf die SSD zu verlegen. Quellcode, Abhängigkeiten, Build-Ausgaben und bei Bedarf ein pnpm-Speicher liegen dann gemeinsam auf einem Laufwerk. Am alten Ort genügt ein einziger symbolischer Link. Das ist übersichtlicher als viele einzelne Links und vermeidet Konstellationen, in denen ein Projekt halb intern und halb extern liegt. Wie ein solcher Umzug mit Prüfung und Rückweg abläuft, zeigt die Anleitung zum Auslagern auf eine externe SSD.

Eine sinnvolle Aufteilung sieht oft so aus: Das aktuelle Projekt bleibt intern, damit du auch unterwegs arbeiten kannst. Ruhende Projekte und große Monorepos ziehen auf die SSD, die am Schreibtisch dauerhaft angeschlossen ist.

Worauf du nach dem Umzug achten solltest

Node.js löst symbolische Links standardmäßig in echte Pfade auf. Bundler, Testrunner und Dateibeobachter sehen danach den Pfad auf der SSD. In den meisten Setups ist das unproblematisch, weil alles gemeinsam umgezogen ist. Heikel wird es, wenn Konfigurationsdateien absolute Pfade enthalten oder Werkzeuge Pfade in Caches speichern. Starte nach dem Umzug einmal deinen Dev-Server, den Build und die Tests, und prüfe, ob Dateiänderungen zuverlässig erkannt werden.

Git selbst kommt mit einem verlegten Projektordner in der Regel gut zurecht, weil der .git-Ordner mit umzieht. Eine Ausnahme sind Worktrees: Git speichert ihre Pfade absolut. Solange der alte Pfad über den Link erreichbar bleibt, funktionieren sie weiter. Ziehst du Daten später an einen anderen Ort, zeigt git worktree list den Zustand, und git worktree repair kann die Verweise korrigieren.

Nutzt du Docker mit Bind-Mounts auf Projektordner, prüfe in den Einstellungen von Docker Desktop, ob der neue Ort auf der SSD zu den freigegebenen Pfaden gehört. Weitere typische Fehlerquellen rund um Links sammelt die Seite Symlink-Fallen auf dem Mac.

Wie DevSpace Manager dabei hilft

DevSpace Manager ist eine macOS-App von BRUNIQO, die große Arbeitsordner auf eine dauerhaft angeschlossene externe SSD verlegt. Zu den typischen Kandidaten gehören Node- und npm-Caches, node_modules, SwiftPM-Caches und große Projektordner. Du wählst Quelle und Ziel über die üblichen macOS-Dialoge aus, und der Zugriff der App bleibt auf diese Auswahl begrenzt. Die App kopiert zunächst in einen Staging-Bereich und vergleicht dann jede Datei samt SHA-256-Prüfsumme, Symlink-Ziel, Rechten, Hardlink-Gruppe und erweiterten Attributen. Erst wenn Quelle und Ziel übereinstimmen, schaltet sie um.

Das Original bleibt als Quarantäne für einen möglichen Rollback erhalten, bis du die Freigabe gesondert bestätigst. Ein Rollback reaktiviert den internen Stand vom Zeitpunkt des Umschaltens; was du seitdem auf der SSD geändert hast, bleibt dort und wird nicht automatisch zusammengeführt. Die Auslagerung ersetzt kein unabhängiges Backup. DevSpace Manager ist für den Mac App Store vorgesehen und derzeit noch nicht veröffentlicht. Mehr dazu in der Übersicht zu DevSpace Manager.