Nettoyage du cache Yarn : comment vider le cache Yarn (v1, Berry)

Réponse rapide : Recherches des utilisateurs yarn clear cache et vider le cache yarn, mais le CLI de Yarn utilise yarn cache clean. Vérifiez la version de Yarn que vous utilisez :

yarn --version

Exécutez yarn config get enableGlobalCache pour voir le paramètre effectif. Flags Berry : yarn cache clean --all efface le scope de cache actif ainsi que le miroir si activé ; il ne supprime pas toujours tous les caches globaux et de projet de la machine. yarn cache clean --mirror supprime un miroir distinct uniquement s'il existe, et peut ne rien faire sinon. Vérifications des chemins : Classique yarn cache dir affiche le dossier de cache versionné ; un yarn cache clean supprime sa racine de cache parente. Berry yarn config get cacheFolder.

Vous exécutez yarn install, et la dépendance que vous venez de mettre à jour pointe toujours vers l’ancienne build. Ou votre laptop installe sans problème, mais la CI échoue soudainement après une modification anodine du lockfile. Le comportement du cache dépend de Yarn Classic vs Yarn Berry, le périmètre du cache et si le vrai problème réside dans les lockfiles ou la conception du cache du pipeline, et non seulement dans les tarballs stockés. Pour une meilleure hygiène des dépendances CI, voir l’intégration CI/CD des mises à jour OTA Capacitor.

Table des matières

• Votre build est cassé et le cache Yarn est peut-être le coupable
• Quand et pourquoi vider le cache Yarn
  • Les symptômes qui indiquent un problème de cache
  • Quand ne pas recourir à Yarn clear cache
• yarn cache clean dans Yarn Classic v1
  • Ce que la commande supprime réellement
  • Comment vérifier l'emplacement du cache
• Gestion moderne du cache dans Yarn Berry v2+
  • Berry a changé le modèle de cache
  • Les commandes essentielles dans Berry
• Bonnes pratiques de cache Yarn pour CI/CD et Docker
  • Pourquoi vider le cache dans les pipelines est souvent une erreur
  • Une meilleure approche CI et Docker
• Dépannage de yarn cache clean
  • Quand un nettoyage ciblé laisse encore traîner des packages obsolètes
  • Problèmes de permissions et d'environnement qui ressemblent à des soucis de cache
• Foire aux questions sur le nettoyage du cache Yarn
  • Quelle est la bonne commande pour yarn clear cache ?
  • Comment exécuter yarn cache clean sur Yarn Classic vs Yarn Berry ?
  • Peut-on vider le cache Yarn sans risque ?
  • Quand faut-il éviter de vider le cache Yarn en CI ou dans Docker ?
  • Comment vérifier où Yarn stocke le cache ?
  • Pourquoi des packages obsolètes restent-ils après yarn cache clean ?

Votre build est cassé et le cache Yarn est peut-être le coupable

Voici un scénario classique : vous montez la version d'un package, vous récupérez les derniers changements et vous relancez l'installation. La commande se termine, mais l'app se comporte toujours comme si l'ancienne dépendance était encore là. Quelqu'un suggère alors de vider le cache, et vous vous demandez si c'est une vraie solution ou juste de la superstition.

Cela peut être une vraie solution. Cela peut aussi être une distraction.

Les problèmes de cache se manifestent généralement de quelques manières prévisibles. Un package local ne s'actualise pas. La CI récupère quelque chose d'inattendu. Une nouvelle branche se comporte différemment de la branche principale alors que le lockfile indique que tout devrait correspondre. Si vous traquez déjà une instabilité plus large de votre pipeline, il est utile de coupler le débogage du cache avec une revue de build plus systématique, comme dans ce guide sur résoudre les échecs de build dans les pipelines CI/CD de Capacitor.

Règle pratique : Considérez Yarn clear cache comme un outil de diagnostic, pas comme un rituel de maintenance.

Le piège, c'est que Yarn a fait évoluer son modèle de cache au fil du temps. Dans les anciens projets, le cache est partagé globalement. Dans les nouveaux, le nettoyage du cache peut être local au projet, global, ou les deux, selon les flags de la commande. Alors, quand un collègue suggère de « juste vider le cache Yarn », la première question à poser est : Lequel Yarn ?

C’est pourquoi un bon dépannage du cache commence par le contexte. Machine locale ou runner CI. Yarn v1 ou Berry. Cache partagé ou cache de projet. Une fois que vous le savez, la commande devient précise plutôt qu’un pari.

Quand et pourquoi vider le cache Yarn

Vider le cache Yarn a du sens lorsque vous avez un mode d’échec spécifique en tête. C’est surtout utile lorsque vous devez supprimer des artefacts de packages obsolètes, vous remettre d’un téléchargement cassé, ou vider délibérément les packages stockés pour que Yarn reparte de zéro.

Les symptômes qui indiquent un problème de cache

Certains cas justifient clairement un nettoyage du cache :

• Une dépendance refuse de se mettre à jour : Vous avez changé la version, ou reconstruit un package local, mais les installations récupèrent toujours un artefact plus ancien.
• Les installations échouent comme si l’état persistait : Une machine fonctionne, une autre non, et relancer la même commande reproduit toujours le même mauvais résultat.
• Vous devez libérer de l’espace disque local : C'est plus important sur les machines de développement que dans des environnements CI éphémères.

D'autres situations ressemblent à un problème de cache. Si votre lockfile a changé de manière inattendue, si la configuration d'un workspace est incohérente, ou si un build Docker invalide la mauvaise couche, vider le cache ne réglera pas la cause racine. Les équipes qui travaillent sur des builds d'applications rencontrent souvent ce cas en jonglant entre outils natifs, dépendances JavaScript et mises à jour de plugins. Dans ce contexte, ce guide pratique sur la gestion des dépendances dans les projets Capacitor vaut la peine d'être gardé sous la main.

Si votre objectif est un nettoyage plus large de la machine plutôt qu'un dépannage de packages, un guide au niveau système peut aussi aider. Les développeurs Mac qui veulent nettoyer les caches d'applications pour les utilisateurs Mac découvrent souvent que les gestionnaires de packages ne sont qu'une partie de l'équation côté stockage.

Quand ne pas recourir à Yarn clear cache

N'utilisez pas Yarn clear cache comme première réponse à chaque problème d'installation.

Utilisez-le lorsqu'il y a des signes d'un état de package obsolète ou corrompu. Laissez tomber si le problème vient plutôt de :

Si l'install est incorrecte parce que l'environnement est incorrect, vider le cache ne fera que ralentir la prochaine install erronée.

Cette distinction fait gagner du temps. Beaucoup de debugging inutile vient du fait de traiter le cache comme un bouton reset magique.

yarn cache clean dans Yarn Classic v1

Yarn Classic fonctionne comme beaucoup de développeurs imaginent encore que toutes les versions de Yarn fonctionnent. Il utilise un cache global dans le répertoire utilisateur, et yarn cache clean vide ce cache partagé. La documentation de Yarn Classic le décrit ainsi et précise que le cache est repeuplé à la prochaine yarn ou yarn install exécution selon le modèle de répertoire utilisateur documenté dans la doc du cache Yarn Classic CLI.

Ce que la commande supprime réellement

Pour Yarn v1, la commande de nettoyage par défaut est simple :

yarn cache clean

Cette commande efface le cache partagé, pas seulement le projet en cours. Si vous travaillez sur plusieurs dépôts sur la même machine, cela compte. La prochaine installation dans l'un d'eux devra peut-être récupérer les packages à nouveau.

Cette conception de cache partagé est l'une des raisons pour lesquelles Yarn v1 peut produire des comportements croisés déroutants. Un artefact obsolète dans le cache global peut persister assez longtemps pour affecter différents repos, surtout lors du développement de packages locaux.

Une séquence pratique pour Yarn Classic ressemble généralement à ceci :

1. Exécutez d'abord la commande clean : yarn cache clean
2. Supprimez les artefacts d'installation locaux si nécessaire : node_modules est souvent la prochaine option quand l'état semble encore incohérent.
3. Réinstallez tout de zéro : Exécutez yarn install à nouveau et confirmez que le graphe de dépendances se résout comme prévu.

Comment vérifier l'emplacement du cache

Lorsque vous souhaitez inspecter ou supprimer directement le répertoire du cache, Yarn Classic vous donne le chemin :

yarn cache dir

C'est utile quand la commande CLI ne semble pas résoudre le problème, ou quand vous devez confirmer quel compte utilisateur possède le répertoire du cache dans un environnement partagé ou conteneurisé.

Sur Yarn Classic 1.22, yarn cache dir pointe vers le dossier versionné sous la racine du cache (par exemple v6 sous l’arborescence macOS par défaut ~/Library/Caches/Yarn tree). A full yarn cache clean sans nom de package supprime cette racine de cache parente, et non seulement le sous-dossier versionné. Si vous définissez cache-folder sur un chemin qui stocke aussi des fichiers non-Yarn, un nettoyage complet peut les supprimer. Utilisez une racine de cache dédiée et inspectez le parent de yarn cache dir avant de vider le cache.

Si vous travaillez avec une ancienne toolchain et que vous essayez de garder une configuration locale prévisible, ce guide sur l'installation de Capacitor CLI étape par étape s’associe bien à une réinitialisation propre des dépendances.

Une inspection manuelle du cache est souvent plus utile qu'une seconde commande de nettoyage à l'aveugle.

Pour les projets v1, le modèle mental est simple. Un cache partagé, une commande de nettoyage globale, et l’installation suivante réinstalle ce que vous avez supprimé.

Gestion moderne du cache dans Yarn Berry v2+

Yarn Berry a changé la donne. Si vous avez l'habitude de Yarn v1, le plus gros changement est que le nettoyage du cache ne consiste plus seulement à « effacer le store global et réessayer ». Berry permet un contrôle plus précis, ce qui est utile une fois que vous savez ce que vous ciblez.

Berry a changé le modèle de cache

Avec le Yarn moderne, le comportement du cache est beaucoup plus étroitement lié au projet lui-même. Cela correspond à l'approche plus large de Berry autour du contrôl’au niveau du projet, du Plug’n’Play et des workflows où les dépendances peuvent coexister avec le repo plutôt que dans un modèle de cache unique à l'échelle de la machine.

C'est pourquoi les vieux conseils peuvent vous induire en erreur. Un collègue ayant appris Yarn sur la v1 pourrait s'attendre à ce qu'une seule commande purge tout globalement. Avec Berry, vous devez penser en termes de périmètre.

Si vous faites face à des builds différents entre vos pipelines mobile et web, cette même approche s'applique également en dehors de la gestion des packages. Cette comparaison de types de builds est un rappel utile : les hypothèses sur l’environnement finissent souvent par polluer le débogage.

Voici une explication visuelle rapide avant de détailler la commande :

Les commandes essentielles dans Berry

Yarn moderne documente yarn cache clean dans la référence actuelle de la commande yarn cache clean. La portée dépend de la valeur effective enableGlobalCache de yarn config get enableGlobalCache:

• Avec enableGlobalCache: true (par défaut sur Yarn 4+), yarn cache clean vide le cache global partagé que Yarn utilise directement.
• Avec enableGlobalCache: false (par défaut sur Yarn 2 et 3), yarn cache clean vide le répertoire de cache actif (par défaut ./.yarn/cache, souvent versionné pour le zero-install ; un cache personnalisé cacheFolder peut pointer ailleurs et est également supprimé).
• yarn cache clean --all vide le périmètre de cache actif et un miroir distinct lorsqu'il est activé. Avec enableMirror: false, le cache global d'un autre projet peut subsister. Avec enableGlobalCache: true, un ancien cache local au projet .yarn/cache peut subsister.
• yarn cache clean --mirror efface uniquement le cache miroir séparé s'il existe. Si Yarn utilise déjà le cache global directement, --mirror il peut ne rien supprimer.

Utiliser --all pour le nettoyage le plus complet que Berry propose pour la configuration actuelle, puis vérifiez avec yarn config get cacheFolder et inspectez ce chemin si des fichiers obsolètes subsistent. Utilisez --mirror uniquement après avoir confirmé que le projet utilise un miroir.

Point de décision : Dans Berry, choisir le mauvais scope est l’une des principales raisons pour lesquelles un nettoyage du cache semble « ne rien faire ».

Voilà la différence concrète. Yarn Classic avait un périmètre large par défaut. Berry est explicite par conception.

Bonnes pratiques de cache Yarn pour CI/CD et Docker

En CI/CD, vider aveuglément le cache Yarn est généralement une erreur. Ça paraît sans risque parce que ça supprime de l'état, mais ça supprime souvent l'état même dont votre pipeline dépend pour sa vitesse et sa répétabilité.

La question la plus utile est la suivante : que mettez-vous exactement en cache, et que restaurez-vous exactement ?

Pourquoi vider le cache dans les pipelines est souvent une erreur

Une discussion sur CircleCI a mis en évidence un type d'échec que beaucoup d'équipes rencontrent en conditions réelles. Les installations lentes ne se réglaient pas avec un nettoyage du cache, car le goulot d'étranglement n'était pas des archives de paquets obsolètes. C'était le comportement de fetch et de link, un répertoire de cache qui ne correspond pas, et l'absence de node_modules chemins dans l'ensemble mis en cache, comme décrit dans ce Fil de cache Yarn sur CircleCI.

C'est important, car les systèmes de CI cachent souvent la cause sous-jacente derrière un symptôme vague : « l'installation est lente » ou « l'étape des dépendances est instable ». Les développeurs vident alors le cache, relancent, et ne constatent aucune amélioration notable.

Les erreurs de pipeline les plus courantes :

• Mettre en cache le mauvais répertoire : L'étape de restauration se termine, mais Yarn n'utilise pas l'emplacement restauré.
• Chemins de workspace ignorés : Les dépendances racine peuvent être restaurées alors que l’installation du workspace doit encore être relinkée.
• Construire les couches Docker dans le mauvais ordre : Une copie source code invalide la couche de dépendances, ce qui force la réinstallation des paquets à chaque fois.

En CI, un cache miss dû à une mauvaise configuration ressemble beaucoup à un cache corrompu.

Si vous compilez des applications mobiles dans des environnements automatisés, c’est aussi là que les outils de release entrent en jeu. Les équipes combinent souvent GitHub Actions ou CircleCI avec des systèmes de distribution et de mise à jour. Une option dans ce workflow plus large est la configuration CI/CD de Capgo pour les apps Capacitor, et Découvrez le build cloud Capgo pour les builds natifs distants, avec votre gestionnaire de paquets et votre stratégie de cache de build.

Une meilleure approche CI et Docker

Utilisez l’invalidation du cache de manière délibérée, pas émotionnelle.

Pour la CI, un modèle fiable ressemble à ceci :

1. Cache basé sur l’état des dépendances : Associer les clés de cache à yarn.lock et aux fichiers de configuration Yarn pertinents.
2. Restaurer avant l’installation : Vérifier que les chemins restaurés correspondent à ceux que Yarn utilisera dans cet environnement.
3. Installer de manière cohérente : Dans les configurations immuables, utilisez le mode d’installation qui impose la validité du lockfile.
4. Invalidez en cas de changements réels : A Yarn version change, lockfile update, or cache-path change is a good reason to rebuild cache.

Pour Docker, les principes sont similaires :

• Copiez d'abord les manifestes de dépendances : Séparez la couche d'installation des dépendances du code source de l'application quand c'est possible.
• Évitez les nettoyages inutiles lors du build de l'image : Supprimer le cache au sein du même build empêche souvent la réutilisation des couches utiles.
• Soyez explicite sur la propriété utilisateur : Les répertoires de cache créés par root peuvent entraîner des échecs d'installation ultérieurs pour un utilisateur d'exécution non-root.

Un tableau de décision rapide peut aider :

N'utilisez Yarn clear cache en CI que si vous avez confirmé que le contenu obsolète du cache est bien le problème. La plupart du temps, la solution réside dans une meilleure conception du cache.

Dépannage de yarn cache clean

Le bug de cache le plus frustrant est celui qui survit à un nettoyage du cache. Vous lancez un nettoyage ciblé, vous réinstallez, et Yarn récupère toujours l'ancien package. À ce stade, on est tenté de penser que le registry est erroné ou que le lockfile est hanté.

Un problème historique documenté dans Yarn explique pourquoi cela arrive. Des développeurs ont signalé que yarn cache clean <package-name> pouvait laisser une ancienne copie dans cache/.tmp, ce qui signifie que les installations utilisaient la version obsolète jusqu'à la suppression de ce répertoire temporaire ou l'exécution d'un nettoyage complet, comme mentionné dans le ticket Yarn concernant les artefacts de cache obsolètes dans .tmp.

Quand un nettoyage ciblé laisse encore traîner des packages obsolètes

La leçon est simple. Un nettoyage partiel ne suffit pas toujours.

Si vous suspectez une version obsolète plutôt qu’une corruption généralisée, suivez cet ordre :

• Commencez par le contrôl’évident : Confirmez que vous déboguez la version du package et la source attendues.
• Ne faites pas trop confiance à un nettoyage ciblé par package : Un nettoyage ciblé peut laisser des artefacts temporaires.
• Passez à une purge complète du cache : Sur Classic, exécutez yarn cache clean sans nom de package, puis yarn install. Sur Berry, utilisez yarn cache clean --all pour la portée la plus large que votre configuration permet.
• Inspect temp cache paths manually: Dans les configurations plus anciennes, cache/.tmp peut être l’élément manquant.

Lorsqu’un package continue de pointer vers un ancien artefact, les fichiers de cache temporaires sont souvent le premier endroit que j’inspecterais après l’échec d’un nettoyage ciblé.

Problèmes de permissions et d'environnement qui ressemblent à des soucis de cache

Toutes les « erreurs de cache » ne sont pas liées au contenu du cache.

Dans Docker, les systèmes Linux multi-utilisateurs ou les runners CI, vous pouvez rencontrer des échecs de permission car le répertoire de cache appartient à un autre utilisateur que le processus qui exécute Yarn. Dans ce cas, vider le cache ne servira à rien tant que le problème de propriété n'est pas résolu. La solution pratique : exécuter Yarn avec le bon utilisateur ou réparer la propriété du répertoire avant de réinstaller.

Ce type de problème ressemble souvent à un cache obsolète, car les installations échouent de façon incohérente d'un environnement à l'autre. Le correctif est opérationnel, pas lié au package.

Foire aux questions sur le nettoyage du cache Yarn

Quelle est la bonne commande pour yarn clear cache ?

Yarn ne fournit pas de yarn clear cache sous-commande. La commande documentée est yarn cache clean. Sur Yarn Classic v1, elle vide le cache global dans votre répertoire utilisateur. Sur Yarn Berry v2 et versions ultérieures, l’étendue dépend des drapeaux et du enableGlobalCache depuis yarn config get enableGlobalCache.

Comment exécuter yarn cache clean sur Yarn Classic vs Yarn Berry ?

Activé Classique v1, exécutez yarn cache clean, puis yarn install. Inspectez le chemin avec yarn cache dir. Sur Berry, exécutez yarn config get enableGlobalCache (Yarn 4+ est true par défaut ; Yarn 2 et 3 sont false par défaut). yarn cache clean efface la portée de cache active. Utilisez yarn cache clean --all pour le scope actif, plus un miroir s’il est activé ; d’autres caches globaux ou de projet peuvent encore rester sur le disque. Utilisez --mirror uniquement si un miroir distinct existe.

Peut-on vider le cache Yarn sans risque ?

Oui, pour un développement normal. Le nettoyage supprime les archives de paquets téléchargées, pas le code source de votre application. La prochaine installation peut être plus longue. Sur Classic, yarn cache dir affiche le dossier de cache versionné, mais un yarn cache clean nettoyage complet supprime la racine du cache parent. Inspectez ce dossier parent et utilisez un cache-folder si vous l’avez personnalisé. Sur Berry, exécutez yarn config get cacheFolder avant un nettoyage complet. yarn cache clean et yarn cache clean --all supprimez l’ensemble du répertoire de cache effectif. Avec enableGlobalCache: false, ce chemin est généralement ./.yarn/cache, mais un chemin personnalisé cacheFolder peut cibler un parent tel que .yarn et supprime les autres fichiers de projet stockés à cet endroit. Lorsqu’un miroir séparé est activé, yarn cache clean --all supprime également le cache sous globalFolder. Exécutez yarn config get globalFolder avant --all if that path may hold other files. Treat full cleans as a debugging step, not daily maintenance.

Quand faut-il éviter de vider le cache Yarn en CI ou dans Docker ?

Évitez de vider le cache par routine lorsque les installations sont lentes mais que les lockfiles sont corrects. Corrigez d’abord les clés de cache, les chemins de restauration et l’ordre des couches Docker. Videz le cache uniquement si vous avez des preuves d’artefacts de packages obsolètes ou corrompus, et non comme étape de réessai par défaut.

Comment vérifier où Yarn stocke le cache ?

Activé Classique v1, exécutez yarn cache dir. Sur Berry, exécutez yarn config get cacheFolder, yarn config get enableGlobalCache, et yarn config get globalFolder lorsqu’un miroir ou yarn cache clean --all est en jeu. Vérifiez que l’utilisateur exécutant Yarn possède ces répertoires dans les CI et les conteneurs.

Pourquoi des packages obsolètes restent-ils après yarn cache clean ?

Les nettoyages ciblés peuvent laisser des fichiers dans des dossiers temporaires tels que cache/.tmp sur les anciennes versions de Yarn. Sur Classic, exécutez yarn cache clean sans nom de package, puis yarn install. Sur Berry, utilisez yarn cache clean --all, supprimez node_modules si nécessaire, réinstallez et inspectez les chemins temporaires si un package résout toujours vers une ancienne version.

Si votre équipe déploie Capacitor apps et a besoin d'un pipeline de release plus propre après des problèmes de dépendances ou de build, Capgo est une option pour livrer des mises à jour de JavaScript et d'assets sans attendre la validation des stores, tout en gardant votre processus de build et de déploiement progressif distinct du dépannage du cache des packages.