# Pourquoi Mole conserve plus de cache que npm cache verify

> Un test sur une copie du cache npm explique ce que Mole conserve, comment Go gère les fichiers récents et où restent certains fichiers de compilation.

Published: 2026-10-05

Un utilisateur m'a récemment signalé que le cache npm était toujours là après une opération de maintenance avec Mole, et qu'en le nettoyant lui-même il était passé de 8 Go à 2 Go. J'ai donc regardé de plus près les caches des outils de développement : quels fichiers servent encore, lesquels ont perdu leurs références, et quels outils font déjà le ménage sans que Mole ait à provoquer une nouvelle compilation.

Cette enquête et ces changements datent du 5 octobre. Ils sont dans le code pour une prochaine version ; la version Preview actuellement disponible ne les contient pas encore.

## Pourquoi le cache npm continue de grossir

Le cache par défaut de npm est `~/.npm/_cacache`. `content-v2` conserve les paquets et les réponses du registre, tandis que `index-v5` associe les requêtes à leur contenu. Les fichiers portent le hash de leur contenu et plusieurs entrées peuvent référencer le même fichier.

Quand les métadonnées d'un paquet changent, npm écrit une nouvelle réponse. Des consultations ultérieures peuvent supprimer les anciennes entrées de l'index sans supprimer leurs fichiers, qui restent alors sans référence. La [documentation npm](https://docs.npmjs.com/cli/v11/commands/npm-cache/) précise aussi que le cache ne supprime pas les données de lui-même et grandit avec les installations.

L'utilisateur avait déjà nettoyé son cache. Je n'avais donc ni copie antérieure ni confirmation de la commande exacte. Le passage de 8 Go à 2 Go a lancé l'enquête ; ce n'est pas une mesure de 6 Go récupérés par Mole, ni la preuve que ces 6 Go étaient tous sans référence.

## Ce que verify a supprimé dans ce test

L'expérience a porté sur des copies du cache de ce Mac, avec npm 11.19.1 et cacache 20.0.4. L'original n'a pas été modifié. Le cache avait environ un jour et contenait 309796162 octets, pas plusieurs mois d'accumulation.

| Critère | Fichiers de contenu | Octets de contenu |
| --- | --- | --- |
| Aucune entrée valide de l'index ne les référence | 1 | 614295 |
| Réellement supprimés par `npm cache verify` | 6 | 25469972 |

La différence vient de [l'implémentation de verify dans cacache](https://github.com/npm/cacache/blob/v20.0.4/lib/verify.js). Elle nettoie le contenu, vérifie son intégrité puis reconstruit l'index en gardant la dernière entrée de chaque clé. Les entrées précédentes peuvent pourtant contenir des métadonnées complètes ou abrégées destinées à des requêtes différentes, plutôt que deux versions du même document.

Sur la copie, 11199796 octets supprimés par verify étaient encore référencés par des entrées valides d'une autre variante de requête. Des informations de paquets lisibles hors ligne avant le nettoyage ont ensuite renvoyé `ENOTCACHED` avec `npm view` hors ligne. Elles pouvaient être téléchargées de nouveau, mais le comportement du cache avait changé.

Mole applique donc un critère plus strict : tant qu’une entrée valide de l’index pointe vers un fichier, celui-ci est conservé. Trouver seulement environ 0,6 Mo dans cet échantillon ne justifie pas d'évincer une variante encore utilisable pour se rapprocher du résultat de verify.

## Nettoyer les fichiers inutilisés sans vider tout le cache

La nouvelle implémentation ne parcourt que le chemin par défaut `~/.npm/_cacache`. Le contenu sans référence de plus d'un jour apparaît sur une ligne présélectionnée du groupe des outils de développement. Supprimer tout le cache npm reste un choix à examiner, et les sélections qui se recouvrent ne comptent les octets qu'une fois.

Pendant que des commandes comme `npm install` ou `npm ci` écrivent dans le cache, Mole ne propose pas ces fichiers au nettoyage. Si l’index est illisible, les fichiers ne sont pas proposés non plus. Les références sont revérifiées avant la suppression ; l'index et les répertoires temporaires restent intacts. Mole n'exécute pas le nettoyage de npm en arrière-plan.

Conserver les références de l'index ne garantit pas que chaque projet pourra toujours être compilé hors ligne. Un fichier de verrouillage peut chercher directement une archive par son hash, et les registres privés ou les anciennes versions ne restent pas forcément disponibles. Sources, fichiers de verrouillage et fichiers impossibles à recréer doivent être conservés séparément. Les chemins de cache npm personnalisés ne sont pas couverts ici.

## Go, Cargo et pnpm demandent des décisions différentes

Go nettoie déjà son cache de compilation. Son [implémentation](https://go.dev/src/cmd/go/internal/cache/cache.go) conserve les entrées utilisées depuis moins de cinq jours, avec une marge d'une heure, soit 121 heures. Mole proposait auparavant le répertoire entier dans le nettoyage présélectionné. Le changement limite cela à la même règle d'âge, en conservant les entrées récentes pour éviter de devoir les recompiler.

Cargo dispose d'un [nettoyage automatique du cache](https://doc.rust-lang.org/cargo/reference/config.html#cache), et cet échantillon n'avait rien d'expiré. Une suppression antérieure des sources extraites du registre avait été suivie, environ 29 heures plus tard, de quelque 157 Mo de téléchargements et 1,06 Go de fichiers décompressés. Mole n’ajoute pas de nettoyage automatique distinct pour ce stockage ; les éléments existants restent disponibles pour un nettoyage manuel, après vérification.

Le stockage partagé de pnpm est encore différent. Dans l'échantillon APFS étudié, le nombre de liens physiques ne prouvait pas qu'un fichier était inutilisé ; reprendre ce critère aurait sélectionné tout le stockage. Aucun nouveau collecteur pnpm n'a été ajouté. Pour utiliser ce critère, il faudrait que le nombre de liens physiques indique réellement si un fichier est encore utilisé sur ce système de fichiers.

## Les fichiers de compilation des outils globaux et des anciens projets Xcode

L'installation globale de `pake-cli` contenait un dossier `src-tauri/target` d'environ 1,48 Gio : les fichiers produits par Rust lors de la compilation de Tauri, pas le cache de téléchargement npm. Ces dossiers de compilation portant un `CACHEDIR.TAG` valide écrit par l'outil sont maintenant proposés à l'examen. L'outil installé et ses dépendances `node_modules` restent en place, et ces dossiers ne sont pas proposés pendant une compilation Rust.

L'enquête a aussi trouvé 24 dossiers Xcode DerivedData, environ 9 Gio, dont les chemins de projet enregistrés n'existaient plus. Un dossier entier n'est proposé que si le projet est confirmé absent du disque de démarrage et si Xcode n'a pas utilisé ce cache depuis au moins deux semaines. Un disque externe débranché ou un refus d'accès ne prouve pas la disparition du projet. Ce sont des mesures de cette enquête, pas une capacité promise sur chaque Mac ; recréer ces fichiers prend aussi du temps si le projet doit être recompilé.

## Vérifier ce que l'on nettoie

Cette commande en lecture seule demande à npm le chemin réel de son cache, y compris une configuration personnalisée.

```bash
npm config get cache
```

Une fois les installations et compilations arrêtées, on peut décider d'exécuter `npm cache verify`. Cette commande modifie le cache, elle ne se contente pas de l'inspecter. Les `node_modules` des projets et les commandes installées globalement sont deux catégories distinctes que cette commande ne nettoie pas. Le [guide des caches de développement](https://mole.fit/fr/blog/how-to-clear-dev-caches-mac) décrit l'ensemble du parcours.

---

Canonical HTML page: https://mole.fit/fr/blog/mole-developer-cache-gc
Blog index for agents: https://mole.fit/fr/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt