Yarn Cache Clean: So leeren Sie den Yarn-Cache (v1, Berry)

Kurze Antwort: Menschen suchen yarn clear cache und yarn cache leeren, aber Yarns CLI verwendet yarn cache clean. Prüfe, welche Yarn-Version du nutzt:

yarn --version

Ausführen yarn config get enableGlobalCache um die effektive Einstellung zu sehen. Berry-Flags: yarn cache clean --all leert den aktiven Cache-Scope sowie einen Mirror (falls aktiviert); es werden nicht immer alle globalen und Projekt-Caches auf dem System gelöscht. yarn cache clean --mirror entfernt einen separaten Mirror nur, wenn einer existiert, und ist andernfalls möglicherweise wirkungslos. Pfadprüfungen: Klassisch yarn cache dir gibt den versionierten Cache-Ordner aus; ein vollständiges yarn cache clean entfernt dessen übergeordnetes Cache-Root. Berry yarn config get cacheFolder.

Du führst yarn installaus, und die gerade aktualisierte Abhängigkeit wird immer noch auf den alten Build aufgelöst. Oder die Installation auf deinem Laptop funktioniert, während CI nach einer harmlosen Lockfile-Änderung plötzlich fehlschlägt. Das Cache-Verhalten hängt ab von Yarn Classic gegenüber Yarn Berry, Cache-Scope und ob das eigentliche Problem in Lockfiles oder im Pipeline-Cache-Design liegt, nicht nur in gespeicherten Tarballs. Für umfassendere CI-Abhängigkeits-Hygiene siehe Capacitor OTA-Updates CI/CD-Integration.

Inhaltsverzeichnis

• Dein Build ist kaputt – und der Yarn Cache könnte schuld sein
• Wann und warum du deinen Yarn Cache leeren solltest
  • Die Symptome, die auf Cache-Probleme hindeuten
  • Wann du Yarn clear cache nicht nutzen solltest
• Yarn-Cache bereinigen in Yarn Classic v1
  • Was der Befehl tatsächlich löscht
  • So prüfst du den Cache-Speicherort
• Modernes Cache-Management in Yarn Berry v2+
  • Berry hat das Cache-Modell geändert
  • Die Befehle, die in Berry zählen
• Yarn Cache Best Practices für CI/CD und Docker
  • Warum Cache-Clearing in Pipelines oft der falsche Weg ist
  • Ein besserer Ansatz für CI und Docker
• Yarn cache clean – Fehlerbehebung
  • Wenn ein gezielter Clean veraltete Pakete hinterlässt
  • Berechtigungs- und Umgebungsprobleme, die wie Cache-Probleme aussehen
• Häufig gestellte Fragen zum Leeren des Yarn-Caches
  • Was ist der korrekte Befehl für yarn clear cache?
  • Wie führe ich yarn cache clean in Yarn Classic und Yarn Berry aus?
  • Ist es sicher, den Yarn-Cache zu leeren?
  • Wann solltest du den Yarn-Cache in CI oder Docker nicht leeren?
  • Wie prüfe ich, wo Yarn den Cache speichert?
  • Warum bleiben veraltete Pakete nach yarn cache clean zurück?

Dein Build ist kaputt – und der Yarn Cache könnte schuld sein

Ein bekanntes Muster sieht so aus: Du erhöhst die Version eines Pakets, holst die neuesten Änderungen und führst install erneut aus. Der Befehl wird abgeschlossen, aber die App verhält sich so, als wäre die alte Abhängigkeit noch vorhanden. Dann schlägt jemand vor, den Cache zu leeren, und du fragst dich, ob das eine echte Lösung ist oder nur Aberglaube.

Es kann eine echte Lösung sein. Es kann aber auch eine Ablenkung sein.

Cache-Probleme zeigen sich meist auf einige vorhersehbare Arten. Ein lokales Paket wird nicht aktualisiert. CI zieht etwas Unerwartetes. Ein frischer Branch verhält sich anders als der main-Branch, obwohl die Lockfile besagt, dass alles übereinstimmen sollte. Wenn du bereits größere Pipeline-Instabilität verfolgst, hilft es, das Cache-Debugging mit einer systematischeren Build-Überprüfung zu kombinieren, wie in diesem Guide zu der Behebung von Build-Fehlern in Capacitor CI/CD-Pipelines.

Praktische Regel: Betrachte `yarn cache clean` als Diagnose-Tool, nicht als Wartungsritual.

Der knifflige Punkt: Yarn hat sein Cache-Modell über die Zeit geändert. In älteren Projekten wird der Cache global geteilt. In neueren Projekten kann die Cache-Bereinigung je nach Command-Flags lokal, global oder beides sein. Wenn ein Teammitglied also sagt „Lösch einfach mal den Yarn-Cache“, sollte die erste Frage lauten: welches Yarn?

Deshalb beginnt ein guter Cache-Fix mit dem Kontext: lokale Maschine oder CI-Runner. Yarn v1 oder Berry. Shared Cache oder Project Cache. Sobald du das weißt, wird der Befehl präzise statt hoffnungsvoll.

Wann und warum du deinen Yarn Cache leeren solltest

Den Yarn-Cache zu leeren ist sinnvoll, wenn du ein bestimmtes Fehlerbild im Kopf hast. Am nützlichsten ist es, wenn du veraltete Package-Artefakte entfernen, dich aus einem kaputten Download-Zustand retten oder gespeicherte Packages gezielt löschen willst, damit Yarn alles neu aufbaut.

Die Symptome, die auf Cache-Probleme hindeuten

Einige Fälle sind starke Cache-Kandidaten:

• Eine Dependency lässt sich nicht aktualisieren: Du hast die Version geändert oder ein lokales Package neu gebaut, aber die Installation zieht weiterhin ein älteres Artefakt.
• Installs fail in a way that feels stateful: Eine Maschine funktioniert, eine andere nicht, und das erneute Ausführen desselben Befehls liefert immer wieder dasselbe falsche Ergebnis.
• Du musst lokalen Festplattenspeicher freigeben: Das ist auf Entwicklerrechnern wichtiger als in kurzlebigen CI-Umgebungen.

Andere Situationen wirken nur wie Cache-Probleme. Wenn sich dein Lockfile unerwartet geändert hat, ein Workspace-Setup inkonsistent ist oder ein Docker-Build den falschen Layer invalidiert, behebt das Leeren des Caches nicht die eigentliche Ursache. Teams, die an App-Builds arbeiten, stoßen oft darauf, wenn sie mit Native Tooling, JavaScript-Dependencies und Plugin-Updates jonglieren. In diesem Kontext lohnt es sich, diesen praktischen Überblick über das Dependency-Management in Capacitor-Projekten griffbereit zu halten.

Wenn dein Ziel eine allgemeinere Systembereinigung statt der Fehlerbehebung bei Paketen ist, kann ein Guide auf Systemebene auch helfen. Mac-Entwickler, die App-Caches für Mac-Nutzer bereinigen wollen, stellen oft fest, dass Package Manager nur einen Teil des Speicherplatzproblems ausmachen.

Wann du Yarn clear cache nicht nutzen solltest

Nutze Yarn clear cache nicht als erste Reaktion auf jedes Installationsproblem.

Setze es ein, wenn es Anzeichen für einen veralteten oder korrupten Package-State gibt. Lass es weg, wenn das Problem eher hier liegt:

Wenn die Installation falsch ist, weil die Umgebung falsch ist, macht das Leeren des Caches nur die nächste falsche Installation langsamer.

Diese Unterscheidung spart Zeit. Viel unnötiges Debugging entsteht, wenn man den Cache wie einen magischen Reset-Button behandelt.

Yarn-Cache bereinigen in Yarn Classic v1

Yarn Classic verhält sich so, wie viele Entwickler immer noch von allen Yarn-Versionen annehmen. Es nutzt einen globalen Cache im Benutzerverzeichnis, und yarn cache clean löscht diesen gemeinsamen Cache. Die eigene Dokumentation von Yarn Classic beschreibt es genau so und merkt an, dass der Cache beim nächsten yarn oder yarn install Lauf im User-Verzeichnis-Modus, wie in den Yarn Classic Cache CLI Docs.

Was der Befehl tatsächlich löscht

Für Yarn v1 ist der Standard-Cleanup-Befehl unkompliziert:

yarn cache clean

Dieser Befehl löscht den gemeinsamen Cache, nicht nur das aktuelle Projekt. Wenn du auf demselben Rechner in mehreren Repositories arbeitest, ist das relevant. Die nächste Installation in einem davon muss möglicherweise Pakete erneut herunterladen.

Dieses Design mit gemeinsamem Cache ist ein Grund, warum Yarn v1 verwirrendes Verhalten zwischen Projekten verursachen kann. Ein veraltetes Artefakt im globalen Cache kann lange genug überleben, um verschiedene Repos zu beeinflussen, besonders wenn lokale Paketentwicklung im Spiel ist.

Eine praktische Abfolge für Yarn Classic sieht in der Regel so aus:

1. Führe zuerst den Clean-Befehl aus: yarn cache clean
2. Entferne lokale Installations-Artefakte bei Bedarf: node_modules ist oft der nächste Kandidat, wenn der Zustand weiterhin inkonsistent erscheint.
3. Neuinstallation von Grund auf: Ausführen yarn install noch einmal und bestätigen, dass der Abhängigkeitsgraph wie erwartet aufgelöst wird.

So prüfst du den Cache-Speicherort

Wenn du das Cache-Verzeichnis direkt inspizieren oder entfernen möchtest, liefert Yarn Classic den Pfad:

yarn cache dir

Das ist nützlich, wenn der CLI-Befehl das Problem nicht zu beheben scheint oder wenn du in einer geteilten oder containerisierten Umgebung prüfen musst, welcher Benutzeraccount das Cache-Verzeichnis besitzt.

Bei Yarn Classic 1.22 yarn cache dir verweist auf den versionierten Ordner unter dem Cache-Root (zum Beispiel v6 unter dem Standard-macOS- ~/Library/Caches/Yarn Baum). Ein vollständiges yarn cache clean Ohne Paketnamen wird der übergeordnete Cache-Root gelöscht, nicht nur das versionierte Unterverzeichnis. Wenn du cache-folder auf einen Pfad, der auch Nicht-Yarn-Dateien speichert, kann ein vollständiges Löschen diese entfernen. Verwende eine dedizierte Cache-Root und prüfe den übergeordneten Ordner von yarn cache dir bevor du den Cache leerst.

Wenn du mit einem älteren Toolchain arbeitest und dein lokales Setup vorhersagbar halten möchtest, passt diese Anleitung zu der Installation von Capacitor CLI Schritt für Schritt gut zu einem sauberen Reset der Abhängigkeiten.

Eine manuelle Cache-Inspektion ist oft wertvoller als ein zweiter blindes Cleanup-Befehl.

Für v1-Projekte ist das mentale Modell einfach. Ein gemeinsamer Cache, ein breiter Cleanup-Befehl, und die nächste Installation befüllt wieder, was du entfernt hast.

Modernes Cache-Management in Yarn Berry v2+

Yarn Berry hat die Diskussion verändert. Wenn du an Yarn v1 gewöhnt bist, ist die größte Anpassung, dass Cache-Cleanup nicht mehr nur „globalen Store leeren und es erneut versuchen“ bedeutet. Berry unterstützt präzisere Kontrolle, was nützlich ist, sobald du weißt, was du targetst.

Berry hat das Cache-Modell geändert

In modernem Yarn ist das Cache-Verhalten viel enger mit dem Projekt selbst verknüpft. Das passt zu Berries breiterem Ansatz rund um projektbezogene Kontrolle, Plug’n’Play und Workflows, in denen Abhängigkeiten neben dem Repo liegen können, statt in einem einzigen maschinenweiten Cache-Modell.

Deshalb kann veralteter Rat irreführend sein. Ein Teammitglied, das Yarn in v1 gelernt hat, erwartet vielleicht, dass ein einzelner Befehl alles global löscht. In Berry muss man in Begriffen von Scope.

Wenn du mit unterschiedlichen Build-Outputs in Mobile- und Web-Pipelines zu tun hast, gilt dieselbe Scope-Denkweise auch außerhalb des Package-Managements. Dieser Vergleich von Build-Typen ist ein nützlicher Hinweis darauf, dass Umgebungsannahmen oft ins Debugging durchsickern.

Bevor es an die Befehlsdetails geht, hier eine kurze visuelle Erklärung:

Die Befehle, die in Berry zählen

Modernes Yarn dokumentiert yarn cache clean in einem der aktuellen Referenz zum Befehl yarn cache cleandenken. Der Scope hängt vom effektiven enableGlobalCache Wert ab yarn config get enableGlobalCache:

• Mit enableGlobalCache: true (Standard in Yarn 4+), yarn cache clean leert den globalen Shared-Cache, den Yarn direkt verwendet.
• Mit enableGlobalCache: false (Standard in Yarn 2 und 3), yarn cache clean leert das aktive Cache-Verzeichnis (Standard ./.yarn/cache, oft für Zero-Install im Repo; ein benutzerdefiniertes cacheFolder kann auf andere Orte zeigen und wird ebenfalls entfernt).
• yarn cache clean --all leert den aktiven Cache-Scope und ein separates Mirror, falls aktiviert. Mit enableMirror: falsekann der globale Cache eines anderen Projekts verbleiben. Mit enableGlobalCache: truekann ein altes projektlokales .yarn/cache verbleiben.
• yarn cache clean --mirror räumt nur einen separaten Mirror-Cache auf, wenn einer existiert. Wenn Yarn den globalen Cache bereits direkt verwendet, --mirror wird möglicherweise nichts entfernt.

Nutzt --all für die umfassendste Bereinigung, die Berry für die aktuelle Konfiguration bietet, und dann mit yarn config get cacheFolder und diesen Pfad prüfen, falls veraltete Dateien verbleiben. Verwenden --mirror erst nachdem du bestätigt hast, dass das Projekt einen Mirror verwendet.

Entscheidungspunkt: In Berry ist die falsche Scope-Wahl einer der Hauptgründe, warum ein Cache-Clean scheinbar „nichts tut“.

Das ist der praktische Unterschied. Yarn Classic war standardmäßig breit. Berry ist explizit by design.

Yarn Cache Best Practices für CI/CD und Docker

In CI/CD ist das blinde Leeren des Yarn-Caches in der Regel ein Fehler. Es fühlt sich sicher an, weil es State entfernt, aber oft genau den State, auf den deine Pipeline für Geschwindigkeit und Reproduzierbarkeit angewiesen ist.

Die nützlichere Frage lautet: Was genau wird gecacht und was genau wird wiederhergestellt?

Warum Cache-Clearing in Pipelines oft der falsche Weg ist

Eine CircleCI-Diskussion dokumentierte ein Fehlmuster, auf das viele Teams in echten Projekten stoßen. Langsame Installs wurden durch Cache-Cleanup nicht behoben, da die Engstelle nicht in veralteten Package-Archiven lag. Es war das Fetch- und Link-Verhalten, ein Cache-Verzeichnis-Mismatch und fehlende node_modules Pfade im gecachten Set, wie in dem CircleCI Yarn-Caching-Thread.

Das ist relevant, da CI-Systeme die Ursache oft hinter einem vagen Symptom verbergen: „Installation ist langsam“ oder „Dependency-Schritt ist flaky“. Entwickler leeren dann den Cache, führen den Job erneut aus und sehen keine sinnvolle Verbesserung.

Häufige Pipeline-Fehler umfassen:

• Falsches Verzeichnis cachen: Der Restore-Schritt wird abgeschlossen, aber Yarn nutzt den wiederhergestellten Speicherort nicht.
• Workspace-Pfade ignorieren: Root-Dependencies werden zwar wiederhergestellt, aber die Workspace-Installation muss erneut verlinkt werden.
• Docker-Layer in der falschen Reihenfolge bauen: Eine Quellcode-Kopie von code invalidiert den Dependency-Layer, sodass die Paketinstallation jedes Mal neu ausgeführt wird.

In der CI sieht ein Cache-Miss durch fehlerhafte Konfiguration oft aus wie ein korrupter Cache.

Wenn du mobile Apps in automatisierten Umgebungen baust, kommt hier auch das Release-Tooling ins Spiel. Teams kombinieren oft GitHub Actions oder CircleCI mit Distribution- und Update-Systemen. Eine Option in diesem breiteren Workflow ist Capgo CI/CD-Setup für Capacitor Apps, und Stellt Capgo Cloud Build vor für Remote-Native-Builds neben eurer Package-Manager- und Build-Cache-Strategie.

Ein besserer Ansatz für CI und Docker

Setzt Cache-Invalidation bewusst ein, nicht emotional.

Für CI sieht ein zuverlässiges Muster so aus:

1. Cache basierend auf dem Abhängigkeitszustand: Verknüpft Cache-Keys mit yarn.lock und den relevanten Yarn-Konfigurationsdateien.
2. Wiederherstellen vor der Installation: Make sure the restored paths match the paths Yarn will use in that environment.
3. Konsistent installieren: In immutable Setups den Install-Modus verwenden, der die Korrektheit der Lockfile erzwingt.
4. Bei echten Änderungen invalidieren: Eine Yarn-Versionänderung, ein Lockfile-Update oder eine Änderung des Cache-Pfads sind gute Gründe, den Cache neu aufzubauen.

Für Docker gelten ähnliche Prinzipien:

• Kopiere zuerst die Abhängigkeits-Manifeste: Halte die Abhängigkeits-Installations-Ebene wann immer möglich von der Anwendungssource getrennt.
• Vermeide unnötige Bereinigung im Image-Build: Das Löschen des Caches innerhalb desselben Builds entfernt oft nützliche Layer-Wiederverwendung.
• Sei explizit bei der Benutzerbesitzung: Von root erstellte Cache-Verzeichnisse können später Installationsfehler für einen nicht-root Runtime-Benutzer verursachen.

Eine kurze Entscheidungstabelle hilft:

Nutze Yarn clear cache in der CI nur, wenn du bestätigt hast, dass veralteter Cache-Inhalt das eigentliche Problem ist. Meistens ist ein besseres Cache-Design die Lösung.

Yarn cache clean Troubleshooting

Der frustrierendste Cache-Bug ist der, der selbst einen Cache-Clean überlebt. Du machst ein gezieltes Cleanup, installierst neu, und Yarn zieht trotzdem das alte Package. Dann ist es verlockend anzunehmen, die Registry sei falsch oder die Lockfile verflucht.

Ein dokumentiertes historisches Problem in Yarn zeigt, warum das passiert. Entwickler berichteten, dass yarn cache clean <package-name> eine alte Kopie in ... hinterlassen konnte cache/.tmp, was bedeutete, dass Installs weiterhin die veraltete Version nutzten, bis dieses temporäre Verzeichnis entfernt oder ein vollständiges Cleanup ausgeführt wurde, wie in ... diskutiert dem Yarn-Issue über veraltete Cache-Artefakte in .tmp.

Wenn ein gezielter Clean veraltete Pakete hinterlässt

Die Lektion ist einfach. Ein teilweises Aufräumen reicht nicht immer aus.

Wenn du eher veraltete Versionen als eine umfassende Beschädigung vermutest, nutze diese Reihenfolge:

• Beginne mit der offensichtlichen Prüfung: Stelle sicher, dass du die richtige Paketversion und die korrekte Quelle debuggst.
• Verlass dich nicht zu sehr auf ein paketspezifisches Clean: Gezielte Bereinigungen können temporäre Artefakte hinterlassen.
• Wechsle zu einem vollständigen Cache-Wipe: Führe auf Classic aus yarn cache clean ohne Paketnamen, dann yarn install. Auf Berry nutze yarn cache clean --all für den größten Umfang, den deine Konfiguration erlaubt.
• Prüfe die temporären Cache-Pfade manuell: In älteren Setups, cache/.tmp kann das fehlende Puzzleteil sein.

Wenn ein Paket immer wieder zu einem alten Artefakt aufgelöst wird, sind temporäre Cache-Dateien oft der erste Ort, den ich nach einem fehlgeschlagenen gezielten Clean prüfe.

Berechtigungs- und Umgebungsprobleme, die wie Cache-Probleme aussehen

Nicht jeder „Cache-Fehler“ ist ein Problem mit dem Cache-Inhalt.

In Docker, auf Multi-User-Linux-Systemen oder in CI-Runnern können Berechtigungsfehler auftreten, weil das Cache-Verzeichnis einem anderen Benutzer gehört als dem Prozess, der Yarn ausführt. In diesem Fall hilft das Leeren des Caches nicht, bis das Eigentumsproblem behoben ist. Der praktische Ansatz ist, Yarn als den richtigen Benutzer auszuführen oder die Verzeichnisbesitzrechte vor der Neuinstallation zu reparieren.

Dieses Problem tritt oft wie ein veralteter Cache auf, da Installationen in verschiedenen Umgebungen inkonsistent fehlschlagen. Die Lösung ist operativ, nicht paketbezogen.

Häufig gestellte Fragen zum Leeren des Yarn-Caches

Was ist der korrekte Befehl für yarn clear cache?

Yarn bietet keine yarn clear cache Subkommando. Der dokumentierte Befehl ist yarn cache clean. Bei Yarn Classic v1 wird der globale Cache im Benutzerordner gelöscht. Bei Yarn Berry v2 und neuer hängt der Scope von Flags und dem effektiven enableGlobalCache von yarn config get enableGlobalCache.

Wie führe ich yarn cache clean bei Yarn Classic im Vergleich zu Yarn Berry aus?

An Klassisch v1, ausführen yarn cache clean, dann yarn install. Prüfe den Pfad mit yarn cache dir. Auf Berry, führe aus yarn config get enableGlobalCache (Yarn 4+ standardmäßig true; Yarn 2 und 3 standardmäßig false). yarn cache clean leert den jeweils aktiven Cache-Bereich. Verwende yarn cache clean --all für den aktiven Bereich plus einen Mirror, falls aktiviert; es können dennoch andere globale oder Projekt-Caches auf der Platte verbleiben. Verwende --mirror nur, wenn ein separater Mirror existiert.

Ist es sicher, den Yarn-Cache zu leeren?

Ja, für die normale Entwicklung. Beim Leeren werden heruntergeladene Paketarchive entfernt, nicht dein App-Quellcode. Die nächste Installation kann länger dauern. Bei Classic yarn cache dir zeigt den versionierten Cache-Ordner an, aber ein vollständiges yarn cache clean entfernt den übergeordneten Cache-Root. Prüfe diesen übergeordneten Ordner und verwende einen dedizierten cache-folder falls du es anpasst. Auf Berry ausführen: yarn config get cacheFolder vor einem vollständigen Clean. yarn cache clean und yarn cache clean --all entfernt das gesamte effektive Cache-Verzeichnis. Mit enableGlobalCache: false, ist dieser Pfad normalerweise ./.yarn/cache, aber ein benutzerdefiniertes cacheFolder kann einen übergeordneten Ordner wie .yarn zielen und andere dort gespeicherte Projektdateien löschen. Wenn ein separater Mirror aktiviert ist, yarn cache clean --all entfernt auch den Cache unter globalFolder. Ausführen yarn config get globalFolder bevor --all falls dieser Pfad andere Dateien enthalten kann. Behandle vollständige Cleans als Debugging-Schritt, nicht als tägliche Wartung.

Wann solltest du den Yarn-Cache in CI oder Docker nicht leeren?

Überspringe routinemäßiges Leeren des Caches, wenn Installationen langsam sind, die Lockfiles aber korrekt. Behebe zuerst Cache-Keys, Restore-Pfade und die Docker-Layer-Reihenfolge. Leere den Cache nur, wenn du Beweise für veraltete oder beschädigte Paket-Artefakte hast, nicht als Standard-Retry-Schritt.

Wie verifiziere ich, wo Yarn den Cache speichert?

An Klassisch v1, ausführen yarn cache dir. Auf Berry, ausführen yarn config get cacheFolder, yarn config get enableGlobalCache, und yarn config get globalFolder wenn ein Mirror oder yarn cache clean --all kommt ins Spiel. Prüfe in CI und Containern, ob der Benutzer, der Yarn ausführt, die Verzeichnisse besitzt.

Warum bleiben veraltete Pakete nach yarn cache clean erhalten?

Gezielte Bereinigungen können Dateien unter temporären Ordnern wie cache/.tmp bei älteren Yarn-Versionen. Bei Classic ausführen yarn cache clean ohne Paketnamen, dann yarn install. Bei Berry verwenden yarn cache clean --all, entfernen node_modules bei Bedarf, neu installieren und temporäre Pfade prüfen, falls ein Paket weiterhin auf eine alte Version verweist.

Wenn dein Team Capacitor-Apps ausliefert und nach Abhängigkeits- oder Build-Problemen eine sauberere Release-Pipeline braucht, Capgo ist eine Option, um JavaScript- und Asset-Updates auszuliefern, ohne auf das Store-Review zu warten, und deinen Build- und Rollout-Prozess getrennt vom Package-Cache-Troubleshooting zu halten.