• Das Problem. Mint löschte in drei Tagen 11-mal denselben node_modules-Ordner, und er kam jedes Mal zurück. Außerdem löschte Mint 35,4 GB an KI-Modellen, und 34,3 GB davon wurden erneut heruntergeladen.
  • Was wir herausgefunden haben. Unsere Regel fragte nur, ob sich ein Ordner neu erstellen lässt. Das Projekt war in Gebrauch, also kamen die 7,68 GB, die diese Löschungen freigegeben hatten, vollständig zurück, und unterm Strich war nichts gewonnen.
  • Was wir gebaut haben. Modelle haben jetzt einen eigenen Chip unter Safe to clean, und Mint hakt sie nie von sich aus an. Seit Mint 1.0.91 landet ein node_modules-Ordner, der in den letzten sieben Tagen genutzt wurde, unter Keep.

Einen node_modules-Ordner zu löschen ist in einer Hinsicht sicher: Nichts geht verloren, denn npm ci stellt ihn aus dem Lockfile wieder her. Ob dabei Platz frei wird, hängt davon ab, ob das Projekt noch in Gebrauch ist. Unseres war es. Zwischen dem 29. September und dem 2. Oktober löschte Mint denselben node_modules-Ordner 11-mal, und er kam jedes Mal zurück, fünfmal innerhalb von 20 Minuten. In denselben drei Tagen löschte Mint 35,4 GB heruntergeladener KI-Modelle, und 34,3 GB davon wurden erneut heruntergeladen.

Dieser Beitrag dokumentiert, wie unser eigenes Bereinigungstool die falsche Frage gestellt hat. Es fragte, ob sich der Ordner neu erstellen lässt. Entscheidend war aber, ob ihn innerhalb der nächsten Stunde etwas neu erstellen würde.

Der Ordner

Der Ordner gehört zu dem Projekt, mit dem wir unsere Videos machen. Zum Rendern wird er gebraucht: 334 MB Pakete, dazu 197 MB Headless Chrome, das das Videowerkzeug beim ersten Rendern herunterlädt, und 176 MB Render-Cache. Insgesamt etwa 730 MB.

Mint führte ihn unter Safe to clean auf, weil er die Regel erfüllte, die wir damals hatten: Ein node_modules-Ordner mit einem Lockfile daneben lässt sich neu installieren. Darüber, wann das Projekt zuletzt genutzt wurde, sagte die Regel nichts. Seit Ende September öffnet sich Safe to clean mit allen Zeilen angehakt, also war der Ordner jedes Mal schon angehakt, wenn jemand die Liste öffnete.

Elf Löschungen

Jede Löschung war eine Bereinigung, die jemand auf Mints Seite „Disk“ von Hand gestartet hatte, und jede war endgültig. Keine kam von Auto Care. Uhrzeiten in pazifischer Zeit:

removed        installed before   back after
Sep 29 23:31   8h 20m             11m
Sep 30 12:15   12h 32m            2h 18m
Sep 30 14:42   9m                 13m
Sep 30 18:47   3h 53m             2h 9m
Oct 1  00:39   3h 42m             17m
Oct 1  12:49   11h 53m            4h 39m
Oct 1  18:01   33m                12m
Oct 1  21:48   3h 35m             1h 43m
Oct 2  00:40   1h 9m              13h
Oct 2  14:12   33m                19m
Oct 2  15:51   1h 19m             6h 7m

Die Spalte „installed before“ gibt an, wie lange der Ordner seit der vorangegangenen Neuinstallation bestanden hatte; „back after“ reicht bis zur nächsten Neuinstallation. Im Median war der Ordner beim Löschen 3 Stunden und 35 Minuten alt, und bis er wieder da war, vergingen im Median 1 Stunde und 43 Minuten. Einer war neun Minuten alt.

Die 11 Löschungen gaben 7,68 GB frei. Alles kam zurück, unterm Strich war also nichts gewonnen. Jede Neuinstallation ging schnell, 4 bis 11 Sekunden für 257 Pakete, kostete aber trotzdem etwas. In denselben Bereinigungen löschte Mint auch den Download-Cache von npm, also holten die Neuinstallationen die Pakete erneut aus der Registry: 74 MB bei der einzigen Messung, die wir dazu haben. Das einzige Render-Log, das uns vorliegt, zeigt weitere 94 MB Headless Chrome, die erneut heruntergeladen wurden.

Die letzte Löschung kam 28 Minuten, nachdem wir eine Korrektur dafür committet hatten. Die Mint-Installation auf diesem Mac enthielt sie noch nicht.

Die Modelle

Dieselben Bereinigungen entfernten den Hugging-Face-Cache, in dem Python-Werkzeuge heruntergeladene Modelle ablegen. Bei uns lagen dort die drei Modelle, die unsere Video-Pipeline für die Stimme und die Untertitel nutzt: VoxCPM2 (etwa 5 GB), SenseVoiceSmall (0,9 GB) und wav2vec2-base-960h (0,4 GB).

Vom 29. September bis zum 1. Oktober entfernte Mint den ganzen Ordner sechsmal und die drei Modellordner ein weiteres Mal, insgesamt 35,4 GB. Bis zum 3. Oktober waren 34,3 GB wieder da. Die Logs des Downloaders belegen davon 12,6 GB, etwa 17 Minuten Download; den Rest leiten wir aus der Größe des Ordners vor der nächsten Löschung ab. Laut den Aufzeichnungen von Mint war dieser Ordner seit dem 16. August schon 10 weitere Male entfernt worden.

Ein Modell ist kein Cache im üblichen Sinn. Zurück kommt es nur über einen Download von mehreren Gigabyte, und das Werkzeug, das es benötigt, lädt es beim nächsten Start ungefragt wieder herunter.

Was „in Gebrauch“ tatsächlich hieß

Zu prüfen, ob ein Programm die Dateien geöffnet hat, hätte nicht geholfen. npm und das Videowerkzeug öffnen sie für ein paar Sekunden und schließen sie wieder. Zwischen zwei Render-Durchläufen hält sie nichts, und genau dann liefen die Bereinigungen.

Die Anhaltspunkte, die geholfen hätten, stehen alle auf dem Datenträger:

  • Wann er installiert wurde. npm schreibt bei jeder Installation node_modules/.package-lock.json.
  • Wann das Projekt zuletzt ausgeführt oder bearbeitet wurde. Das Videowerkzeug schreibt bei jedem Rendern seine Caches in node_modules (.remotion, .cache), und beim Bearbeiten des Projekts ändern sich seine eigenen Dateien.
  • Ob er zurückkam. Schon nach der ersten Löschung zeigte der Verlauf des Ordners: gelöscht, 11 Minuten später neu angelegt.

So prüfst du deine eigenen Projekte

Dieser Befehl listet jeden node_modules-Ordner unterhalb eines Ordners auf, mit seiner Größe und dem Zeitpunkt, zu dem npm ihn zuletzt installiert hat. Er liest nur. Ersetze ~/Projects durch den Ordner, in dem dein Code liegt:

find ~/Projects -maxdepth 4 -type d -name node_modules -prune |
while read -r d; do
  f="$d/.package-lock.json"
  [ -f "$f" ] && t=$(stat -f %Sm -t %Y-%m-%d "$f") || t="unknown   "
  printf "%6s  installed %s  %s\n" "$(du -sh "$d" | cut -f1)" "$t" "${d%/node_modules}"
done

Ein Ordner, der diese Woche installiert wurde, gehört zu einem Projekt in Gebrauch, und wenn du ihn löschst, bringt dir das nur eine Neuinstallation ein. Entfernen lohnt sich dagegen bei einem Ordner, der vor Monaten installiert wurde, in einem Projekt, an dem du nicht mehr arbeitest. „unknown“ bedeutet, dass npm die Datei nicht geschrieben hat (Yarn und pnpm führen eigene); prüf dann stattdessen den letzten Commit des Projekts. Unsere Anleitung zum Entfernen alter node_modules-Ordner beschreibt, was du vor dem Löschen am Lockfile prüfen solltest.

Was Mint jetzt macht

  • Modelle haben unter Safe to clean einen eigenen Chip, mit einer Zeile pro Modell und dem Datum der letzten Nutzung. Mint hakt sie nie von sich aus an, Auto Care nimmt sie nie mit, und ein Modell, das ein Programm geöffnet hat oder das LM Studio oder Ollama gerade ausführt, wird nicht angeboten. Das kam mit Mint 1.0.82 am 2. Oktober.
  • node_modules eines Projekts, das in den letzten sieben Tagen genutzt wurde, landet mit dem Datum unter Keep. „Genutzt“ heißt installiert, ausgeführt oder bearbeitet, oder dass ein Programm gerade im Projekt arbeitet. Ein Ordner, der gelöscht wurde und zurückkam, wird aufgeführt, aber Mint hakt ihn nie von sich aus an, und Recommended und Auto Care überspringen ihn. Beim Klick prüft Mint noch einmal. Das kam mit Mint 1.0.91 am 9. Oktober.

Fragen

Kann ich node_modules gefahrlos löschen? Es geht nichts verloren, wenn das Projekt ein Lockfile hat und sich jedes Paket noch herunterladen lässt. Arbeitest du bald wieder an dem Projekt, bekommst du den Platz für ein paar Minuten zurück und bezahlst mit einer Neuinstallation.

Warum nicht einfach jeden node_modules-Ordner auslassen? Ordner in Projekten, die seit Monaten niemand angefasst hat, summieren sich. Auf diesem Mac sind sie es, deren Löschen sich lohnt, und sie lassen sich leicht von denen unterscheiden, die in Gebrauch sind.

Gilt das auch für andere Caches? Alles, was ein Werkzeug von selbst wieder füllt, verhält sich genauso. Von den 11 Bereinigungen, die diesen node_modules-Ordner mitnahmen, haben alle 9, zu denen wir vollständige Aufzeichnungen haben, auch den Download-Cache von npm geleert, und die nächste Installation hat ihn wieder heruntergeladen.