Vider les caches développeur sans casser les builds

Le stockage des développeurs est fragmenté entre les téléchargements de paquets, les sorties de compilation, les SDK, les bases de données locales et les arborescences de dépendances par projet. Une partie est reproductible, une autre dépend d’un lockfile et d’un registre qui peut disparaître plus tard, et une autre encore est une donnée locale unique. Un nettoyage sûr prouve de quel type il s’agit, au lieu de supposer que chaque dossier pointé est un cache.

Les caches globaux, par outil

Chaque gestionnaire de paquets conserve un magasin global que vous pouvez mesurer directement :

du -sh ~/.npm ~/.cargo ~/.cache/pip ~/Library/Caches/pip ~/.gradle 2>/dev/null | sort -h

Ce sont des emplacements par défaut, pas une promesse. Demandez à l’outil son chemin configuré lorsque c’est possible, par exemple npm config get cache, python -m pip cache dir et pnpm store path.

• npm met en cache les téléchargements dans ~/.npm par défaut. Commencez par npm cache verify ; npm décrit son cache comme auto-réparant, donc npm cache clean --force sert surtout à une récupération d’espace volontaire ou au dépannage.
• Cargo conserve les registres et les checkouts git sous ~/.cargo, mais le Cargo home peut aussi contenir des binaires installés, de la configuration, des enregistrements de paquets et des identifiants de registre. Cargo actuel retire périodiquement les entrées de cache global inutilisées pendant les commandes de build et de fetch. Laissez cette politique opérer, ou inspectez les sous-dossiers de cache exacts. Ne supprimez jamais tout ~/.cargo.
• pip met en cache les wheels et les réponses HTTP dans ~/Library/Caches/pip par défaut. python -m pip cache info indique l’emplacement et la taille réels, tandis que python -m pip cache purge le vide.
• pnpm et yarn ont chacun leur magasin ; pnpm store prune et yarn cache clean élaguent les paquets non référencés ou mis en cache. Vérifiez la version active du gestionnaire de paquets, car la disposition du magasin et le comportement cache local / global diffèrent.
• Gradle et Maven (~/.gradle, ~/.m2) peuvent être énormes sur les Mac Android et JVM. Gradle effectue déjà un nettoyage périodique du cache ; arrêtez ses daemons avant un examen manuel. Un dépôt Maven peut contenir des artefacts construits localement ou privés qu’on ne peut plus télécharger, donc inspectez-le plutôt que de supprimer tout le dépôt par défaut.

Le coût peut inclure un gros téléchargement, une recompilation native, ou un échec de build historique lorsqu’une version du registre a disparu. Vérifiez le lockfile et la source de chaque dépendance avant de déclarer un magasin reproductible.

Le problème des node_modules dispersés

La plus grande surprise n’est en général pas un seul cache, mais les dossiers node_modules répartis dans tous les projets JavaScript que vous avez déjà touchés. Chacun est autonome et pèse souvent 200 à 500 Mo, donc dix anciens projets peuvent cacher plusieurs gigaoctets. Trouvez-les et leurs tailles :

find ~/www ~/Projects -name node_modules -type d -prune -exec du -sh {} + 2>/dev/null

Remplacez les racines d’exemple par les dossiers où vous gardez vos projets. -prune empêche find de descendre dans une arborescence de dépendances déjà trouvée, et -exec gère correctement les espaces et les caractères inhabituels dans les chemins. Un projet ne peut reconstruire ses dépendances que si sa source, son lockfile, la version du gestionnaire de paquets, l’accès au registre et la toolchain native requise sont encore disponibles. Préférez la commande propre au lockfile, comme npm ci, après avoir préservé ces entrées.

Ne supprimez pas ceci

Les caches de paquets peuvent être remplaçables, mais deux voisins ne le sont pas. Le code source et les lockfiles du projet (package.json, package-lock.json, Cargo.lock) ne sont pas du cache : ils définissent le build, ne les balayez donc jamais. Et un magasin global que vous utilisez activement, comme un magasin pnpm adressé par contenu partagé entre projets, se retéléchargera, mais une suppression en cours d’install peut le corrompre : videz les caches quand rien ne compile.

Sous le capot : magasins adressés par contenu, et pourquoi node_modules est l’exception

Beaucoup de gestionnaires de paquets utilisent des magasins adressés par contenu pour réduire les téléchargements répétés. pnpm conserve un magasin global de chaque version de paquet et les hard-link dans le node_modules de chaque projet, de sorte que dix projets qui utilisent la même bibliothèque partagent une seule copie sur le disque. Les caches Cargo et Go indexent aussi le contenu téléchargé par version ou somme de contrôle. Cela protège l’intégrité, mais ne garantit pas la disponibilité future. Une installation npm classique matérialise une arborescence de dépendances par projet, tandis que pnpm peut lier les projets à un magasin partagé. C’est pourquoi supprimer un dossier node_modules et élaguer un magasin partagé n’ont pas le même rayon d’impact.

Utilisez des cartes pour découvrir, les gestionnaires de paquets pour nettoyer

La nature dispersée est le problème de découverte. Une carte en treemap comme la vue Analyze de Mole peut montrer quel projet ou magasin est volumineux, mais la commande verify, prune ou clean du gestionnaire de paquets comprend son index et ses références. Utilisez la carte pour choisir une cible, et l’outil propriétaire pour la modifier.

Un ordre d’opérations sûr

Arrêtez les builds et les daemons, mesurez les racines de projet sélectionnées, vérifiez les magasins des gestionnaires de paquets, et préservez le code source plus les lockfiles avant de retirer une arborescence de dépendances. Utilisez les commandes de prune documentées plutôt que de supprimer tout un dossier pointé du répertoire personnel. Reconstruisez un projet avant de vider la Corbeille. L’objectif est de retirer la sortie reproductible tout en conservant les informations nécessaires pour la reproduire.