Caches npm et pnpm : là où des gigaoctets se cachent dans AppData

Deux outils, deux modèles de cache

npm entretient un cache adressé par contenu dans %LOCALAPPDATA%\npm-cache : chaque archive jamais téléchargée, plus les logs et le cache _npx des exécutions ponctuelles. Rien de tout cela ne sert à faire tourner les projets installés — le cache n'existe que pour accélérer les installations à venir et travailler hors ligne. pnpm fait autrement : un dépôt unique (dans les versions récentes, %LOCALAPPDATA%\pnpm\store) conserve les vrais fichiers, et chaque dossier node_modules de chaque projet est construit en liens physiques vers lui. C'est pourquoi les projets pnpm ne multiplient pas l'occupation disque comme ceux de npm — et pourquoi le dépôt lui-même croît sans limite : chaque nouvelle version de paquet s'y dépose pour de bon, jusqu'au nettoyage.

D'où la surprise classique : vous supprimez un vieux projet, la place ne revient pas, parce que les liens physiques du dépôt maintiennent les données en vie. Le coupable, c'est le dépôt, pas les dossiers de projets.

Les commandes de nettoyage qui comptent

Tout ce qui suit est sûr par construction : un cache reste un cache, les outils le reconstruisent à la demande :

• npm cache clean --force — vide tout le cache npm ; les prochaines installations retéléchargeront le nécessaire
• npm cache verify — l'option douce : ramasse-miettes et vérification d'intégrité au lieu du ratissage complet
• pnpm store prune — retire du dépôt les paquets auxquels plus aucun projet ne fait référence
• Supprimer %LOCALAPPDATA%\npm-cache\_npx — caches jetables des exécutions npx, toujours sans risque
• npm config set cache D:\dev\npm-cache — déménage définitivement le cache du SSD vers un disque de données
• Mesurez d'abord : un scan des tailles dans AppData vaut mieux qu'une suppression à l'aveugle — npm-cache et le dépôt pnpm sont les deux suspects habituels

Le piège des liens physiques NTFS

Voici la partie qui embrouille tout le monde : sur NTFS, les données d'un fichier ne sont libérées que quand disparaît le dernier lien physique. Supprimer le dépôt pnpm juste après avoir vidé node_modules rend l'espace attendu. Supprimer le dépôt pendant que des projets pointent encore sur ses fichiers ne libère rien : les octets restent sur le disque tant que node_modules existe, et l'Explorateur continue d'afficher des entrées du dépôt qui ne sont plus que des coquilles vides. L'ordre compte : d'abord retirer les projets (ou leurs node_modules), ensuite lancer pnpm store prune. Les runners CI et les machines qui traversent beaucoup de dépôts tirent le meilleur parti d'un passage mensuel ; sur un portable mono-projet, le dépôt mérite rarement l'attention.

Questions et réponses

À lire ensuite