Comment vider le cache npm sur Mac sans risque

Séparer le cache npm des dépendances et fichiers du projet

Le cache npm conserve des téléchargements réutilisables entre plusieurs projets. Son emplacement macOS par défaut est ~/.npm, mais la configuration peut le déplacer. node_modules est l’arbre de dépendances installé dans un projet ; package.json et package-lock.json décrivent son état et ne sont pas du cache. npm-shrinkwrap.json n’est pas du cache non plus, mais npm v12 ne le lit plus : s’il s’agit du seul lockfile d’un ancien projet, renommez ce fichier de même format en package-lock.json avant une réinstallation avec npm v12. N’écrasez jamais un package-lock.json existant.

Mesurer le cache actif et commencer par le vérifier

Ne supposez pas qu’un dossier ~/.npm existant est le cache actif. npm config get cache donne le chemin utilisé par cette configuration : mesurez exactement celui-ci et relevez l’espace libre. npm cache verify contrôle l’index et l’intégrité, puis élimine les données devenues inutiles sans jeter tous les téléchargements valides. Cela suffit souvent à l’entretien courant ; les erreurs ERESOLVE, d’authentification, 404, de proxy, de version de Node.js, de compilation native ou de script postinstall demandent un autre diagnostic.

1. Exécutez npm --version et npm config get cache, puis confirmez que le chemin affiché désigne un cache et non un projet.
2. Mesurez ce chemin exact avec du -sh et notez l’espace libre de macOS sans modifier package.json ni le lockfile.
3. Arrêtez npm install, npm ci, npm exec et toute publication en cours, puis exécutez npm cache verify et conservez son résumé ainsi que ses erreurs.
4. Exécutez npm cache clean --force uniquement si verify ne suffit pas, si le gain est pertinent et si les artefacts nécessaires restent accessibles.
5. Relancez npm cache verify, remesurez le même chemin et validez un projet représentatif avec son lockfile inchangé, son build et ses tests.

Ne transmettez jamais un chemin non vérifié à rm -rf. Ne combinez pas non plus le nettoyage du cache avec la suppression ou la régénération du lockfile : vous changeriez deux causes à la fois et perdriez toute base de comparaison.

Réserver npm cache clean --force aux besoins justifiés

Exécutez npm cache clean --force seulement si le cache mesuré est assez gros pour compter, si l’espace est nécessaire maintenant et si les artefacts pourront être récupérés. La prochaine installation, notamment avec npm ci, peut être plus lente, voire échouer hors ligne ou si un registre privé, un hôte Git, un proxy ou un paquet retiré n’est plus accessible. Limitez --force à cette commande et ne l’enregistrez pas comme réglage npm permanent.

Valider sans modifier le graphe de dépendances

Après le nettoyage, vérifiez à nouveau le chemin avec npm config get cache, remesurez-le et comparez l’espace libre réel de macOS. Testez un projet représentatif en conservant package.json et le lockfile inchangés, puis exécutez son build et ses tests. Si l’erreur initiale revient, ne répétez pas le nettoyage : examinez le message conservé, les versions npm et Node.js, les identifiants et la configuration réseau. AskClean reconnaît ~/.npm par défaut ; un cache personnalisé reste à vérifier avec npm.

Limites de suppression et coût de récupération

Trouvez et mesurez le cache de téléchargement réellement utilisé par npm, vérifiez-le d’abord et ne le videz que si le gain justifie les futurs téléchargements.

FAQ