# Waarom Mole minder npm-cache leegt dan npm cache verify

> Tests op cachekopieën leidden tot een smallere npm-opruiming, de eigen leeftijdsgrens van Go, en beoordeling van buildoutput in globale tools en oude Xcode-projecten.

Published: 2026-10-05 | Updated: 2026-10-18

Een gebruiker zei onlangs dat de cache van npm er nog stond na een onderhoudsronde van Mole, en dat zelf opruimen hem van 8 GB naar 2 GB bracht. Dat was aanleiding om ontwikkelaarscaches opnieuw te bekijken: welke gecachte bestanden nog nodig zijn, welke hun verwijzingen zijn kwijtgeraakt, en welke tools hun eigen oude gegevens al verzamelen.

Het onderzoek en de wijzigingen die hier worden beschreven, zijn gedaan op 5 oktober. Ze zijn meegegaan in Mole 1.16.0.

## Waarom de cache van npm blijft groeien

De standaardcache van npm is `~/.npm/_cacache`. `content-v2` bewaart pakketten en registry-antwoorden, terwijl `index-v5` verzoeken aan die inhoud koppelt. Inhoudsbestanden zijn vernoemd naar een hash, en meerdere indexvermeldingen kunnen naar hetzelfde bestand verwijzen.

Wanneer pakketmetadata verandert, schrijft npm een nieuw antwoord. Latere opzoekingen kunnen oudere indexvermeldingen comprimeren zonder de inhoudsbestanden te verwijderen, waardoor bestanden zonder indexverwijzing achterblijven. De [documentatie van npm](https://docs.npmjs.com/cli/v11/commands/npm-cache/) zegt ook dat de cache gegevens niet zelf verwijdert en groeit naarmate pakketten worden geïnstalleerd.

De gebruiker had de cache al opgeruimd, dus ik had geen kopie van vóór het opruimen en kon het exacte commando dat ze hebben uitgevoerd niet bevestigen. Het bericht van 8 GB naar 2 GB startte dit onderzoek; het is geen meting dat Mole 6 GB heeft teruggewonnen, en geen bewijs dat alle 6 GB geen verwijzingen hadden.

## Wat verify in deze test verwijderde

Het experiment gebruikte kopieën van de cache van mijn Mac met npm 11.19.1 en cacache 20.0.4. Het origineel bleef ongewijzigd. Het was ongeveer een dag oud, met 309796162 bytes inhoud, in plaats van een cache die over enkele maanden is opgebouwd.

| Regel | Inhoudsbestanden | Inhoudsbytes |
| --- | --- | --- |
| Door geen geldige indexvermelding genoemd | 1 | 614295 |
| Werkelijk verwijderd door `npm cache verify` | 6 | 25469972 |

Het verschil komt uit de [verify-implementatie van cacache](https://github.com/npm/cacache/blob/v20.0.4/lib/verify.js). Die verzamelt inhoud, controleert de integriteit en bouwt de index opnieuw op, en houdt de laatste vermelding per sleutel. Eerdere vermeldingen kunnen nog volledige en afgekorte metadata bevatten die door verschillende verzoeken worden gebruikt; dat zijn niet simpelweg oude en nieuwe kopieën van één antwoord.

Op de kopie werden 11199796 bytes die verify verwijderde nog genoemd door geldige vermeldingen voor een andere verzoekvariant. Sommige pakketinformatie die offline gelezen kon worden vóór de verificatie, gaf daarna `ENOTCACHED` terug bij een offline `npm view`. Die kon online opnieuw worden opgehaald, maar het gedrag van de cache was veranderd.

Mole neemt de smallere regel: elke geldige indexvermelding houdt de inhoud. In dit monster alleen ongeveer 0,6 MB vinden is te verkiezen boven een bruikbare variant verwijderen alleen om dichter bij het resultaat van verify te komen.

## Ongebruikte bestanden wissen zonder de hele cache te wissen

De nieuwe implementatie scant alleen de standaard `~/.npm/_cacache`. Inhoud zonder verwijzing die ouder is dan een dag verschijnt als één standaard geselecteerde rij in het ontwikkelaarsgedeelte van Opschonen. De hele npm-cache verwijderen vraagt nog steeds om beoordeling, en overlappende selecties tellen hun bytes één keer.

Mole laat deze bestanden met rust terwijl commando's zoals `npm install` of `npm ci` naar de cache schrijven. Als de index niet gelezen kan worden, worden de bestanden niet voor opruiming aangeboden. Verwijzingen worden opnieuw gecontroleerd vóór verwijdering; indexbestanden en tijdelijke mappen blijven staan. Mole voert het opruimcommando van npm niet op de achtergrond uit.

Indexverwijzingen bewaren garandeert niet dat elk project altijd offline kan bouwen. Een lockbestand kan een tarball rechtstreeks op hash vragen, en privéregisters of oude versies blijven mogelijk niet beschikbaar. Bronbestanden, lockbestanden en buildoutput die niet opnieuw kan worden gemaakt, moeten apart worden bewaard. Aangepaste locaties van de npm-cache vallen buiten deze wijziging.

## Go, Cargo en pnpm vragen om andere beslissingen

Go snoeit de buildcache al. De [implementatie](https://go.dev/src/cmd/go/internal/cache/cache.go) houdt vermeldingen die binnen vijf dagen plus een marge van één uur zijn gebruikt, of 121 uur. Mole bood eerder de hele buildcachemap aan voor standaardopruiming; deze wijziging versmalt dat tot dezelfde leeftijdsregel, en houdt recente vermeldingen die anders opnieuw gebouwd zouden moeten worden.

Cargo heeft al [automatische cacheverzameling](https://doc.rust-lang.org/cargo/reference/config.html#cache), en niets in dit monster was daarvoor aan de beurt. Een eerdere verwijdering van uitgepakte registrybronnen werd ongeveer 29 uur later gevolgd door ruwweg 157 MB downloads en 1,06 GB uitpakken. Mole voegt geen aparte automatische verzamelaar voor die opslag toe; de bestaande rijen die alleen ter beoordeling zijn, blijven beschikbaar.

De gedeelde store van pnpm is weer anders. In het APFS-monster konden hardlink-tellingen niet bewijzen dat inhoud ongebruikt was; dat criterium kopiëren zou de hele store selecteren. Er is geen nieuwe pnpm-verzamelaar toegevoegd. De hardlink-telling zou moeten laten zien of een bestand op dat bestandssysteem nog in gebruik is voordat Mole hem voor opruiming zou kunnen gebruiken.

## Buildoutput in globale tools en oude Xcode-projecten

De globaal geïnstalleerde `pake-cli` bevatte een map `src-tauri/target` van ongeveer 1,48 GiB: Rust-output van het bouwen van de Tauri-schil, niet de downloadcache van npm. Zulke buildmappen met een geldige door de tool geschreven `CACHEDIR.TAG` worden nu ter beoordeling aangeboden. Mole houdt de geïnstalleerde tool en de afhankelijkheden in `node_modules`, en biedt deze mappen niet aan terwijl een Rust-build draait.

Het onderzoek vond ook 24 mappen Xcode DerivedData, ongeveer 9 GiB, waarvan de vastgelegde projectpaden niet meer bestonden. Een hele map wordt alleen aangeboden wanneer het project bevestigd ontbreekt op de opstartschijf en Xcode de bijbehorende cache minstens twee weken niet heeft gebruikt. Een afwezige externe schijf of geweigerde leestoegang stelt geen ontbrekend project vast. Dit zijn bevindingen uit dat onderzoek, geen beloofde besparing op elke Mac; opnieuw bouwen kost nog steeds tijd als de output weer nodig is.

## Controleer welke laag je opruimt

Dit alleen-lezen-commando vraagt npm om de echte cachelocatie, inclusief een geconfigureerd aangepast pad.

```bash
npm config get cache
```

Zodra installaties en builds niet meer naar die cache schrijven, beslis je of je `npm cache verify` uitvoert. Dat wijzigt de cache; het is geen commando dat alleen inspecteert. Mappen `node_modules` van projecten en globaal geïnstalleerde commando's zijn aparte lagen die het niet opruimt. De [gids voor ontwikkelaarscaches](https://mole.fit/nl/blog/how-to-clear-dev-caches-mac) behandelt de bredere werkwijze.

---

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