Ontwikkelaarscaches legen zonder builds te breken

Ontwikkelaarsopslag ligt versnipperd over packagedownloads, builduitvoer, SDK's, lokale databases en dependencybomen per project. Een deel is reproduceerbaar, een deel hangt af van een lockfile en een registry die later kan verdwijnen, en een deel is unieke lokale gegevens. Een veilige opschoning bewijst welk soort het vond, in plaats van aan te nemen dat elke puntmap cache is.

De globale caches, per hulpmiddel

Elke pakketbeheerder houdt een globale store bij die je direct kunt meten:

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

Dit zijn standaarden, geen belofte. Vraag het hulpmiddel om het geconfigureerde pad wanneer dat kan, bijvoorbeeld npm config get cache, python -m pip cache dir en pnpm store path.

• npm cachet downloads standaard in ~/.npm. Begin met npm cache verify; npm beschrijft de cache als zelfherstellend, dus npm cache clean --force is vooral voor bewust ruimte terugwinnen of voor storingzoeken.
• Cargo bewaart registries en git-checkouts onder ~/.cargo, maar de Cargo-home kan ook geïnstalleerde binaries, configuratie, pakketrecords en registry-inloggegevens bevatten. Huidige Cargo verwijdert periodiek ongebruikte globale cache-items tijdens build- en fetch-commando's. Laat dat beleid werken, of inspecteer de precieze cache-submappen. Verwijder nooit heel ~/.cargo.
• pip cachet wheels en HTTP-antwoorden standaard in ~/Library/Caches/pip. python -m pip cache info meldt de echte locatie en grootte, terwijl python -m pip cache purge die leegt.
• pnpm en yarn houden hun eigen stores bij; pnpm store prune en yarn cache clean snoeien niet-verwezen of gecachte pakketten. Controleer de actieve versie van de pakketbeheerder, omdat de indeling van de store en het verschil tussen lokale en globale cache kunnen verschillen.
• Gradle en Maven (~/.gradle, ~/.m2) kunnen enorm zijn op Android- en JVM-Macs. Gradle doet al periodieke cache-opschoning; stop de daemons voordat je met de hand beoordeelt. Een Maven-repository kan lokaal gebouwde of privéartefacten bevatten die niet opnieuw te downloaden zijn, dus inspecteer die in plaats van de hele repository standaard te verwijderen.

De kosten kunnen een grote download zijn, een native herbouw, of een mislukte historische build wanneer een registryversie weg is. Controleer de lockfile en de bron van elke dependency voordat je een store reproduceerbaar noemt.

IDE-caches zijn een aparte laag. JetBrains-IDE's bewaren caches, indexen en Local History onder ~/Library/Caches/JetBrains, en JetBrains-caches op de Mac behandelt welke delen opnieuw opbouwen. Android Studio, hoewel op hetzelfde platform gebouwd, bewaart de caches onder ~/Library/Caches/Google/AndroidStudio* in plaats daarvan.

Het verspreide node_modules-probleem

De grotere verrassing is meestal niet één cache, maar de node_modules-mappen verspreid over elk JavaScript-project dat je ooit hebt aangeraakt. Elk is zelfstandig en vaak 200 tot 500 MB, dus tien oude projecten kunnen enkele gigabytes verbergen. Vind ze en hun groottes:

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

Vervang de voorbeeldwortels door de mappen waar je projecten bewaart. -prune zorgt dat find niet afdaalt in een gevonden dependencyboom, en -exec gaat veilig om met spaties en ongebruikelijke tekens in paden. Een project kan dependencies alleen opnieuw opbouwen wanneer de bron, de lockfile, de versie van de pakketbeheerder, toegang tot de registry en de vereiste native toolchain nog beschikbaar zijn. Geef de voorkeur aan het lockfile-specifieke commando, zoals npm ci, nadat je die invoer hebt bewaard.

Verwijder dit niet

Pakketcaches kunnen vervangbaar zijn, maar bron, manifesten en lockfiles van een project niet. package.json is een manifest; package-lock.json en Cargo.lock zijn lockfiles. Ze definiëren de build, dus veeg ze nooit mee. Een actieve globale store verwijderen, zoals een pnpm-store die projecten delen, kan de installatie onderbreken of downloads eisen die niet meer beschikbaar zijn. Stop builds en installaties, en gebruik daarna de gedocumenteerde opschoning van de pakketbeheerder.

Onder de motorkap: content-addressed stores, en waarom node_modules de uitzondering is

Veel pakketbeheerders gebruiken content-addressed stores om herhaalde downloads te beperken. pnpm houdt één globale store bij van elke pakketversie en hardlinkt die in de node_modules van elk project, zodat tien projecten die dezelfde bibliotheek gebruiken één kopie op schijf delen. Cargo- en Go-caches sleutelen gedownloade inhoud ook op versie of checksum. Dat beschermt de integriteit, maar garandeert toekomstige beschikbaarheid niet. Een gewone npm-install materialiseert een dependencyboom per project, terwijl pnpm projecten aan een gedeelde store kan koppelen. Daarom hebben het verwijderen van één node_modules-map en het snoeien van een gedeelde store een verschillende explosieradius.

Gebruik kaarten om te ontdekken, pakketbeheerders om op te schonen

De verspreiding is het ontdekkingsprobleem. Een treemap zoals de Analyseweergave van Mole kan laten zien welk project of welke store groot is, maar het eigen verify-, prune- of clean-commando van de pakketbeheerder begrijpt de index en de verwijzingen. Gebruik de kaart om een doel te kiezen en het hulpmiddel dat eigenaar is om het te wijzigen.

Een veilige volgorde

Stop builds en daemons, meet gekozen projectwortels, controleer de stores van de pakketbeheerder, en bewaar bron plus lockfiles voordat je een dependencyboom verwijdert. Gebruik gedocumenteerde prune-commando's in plaats van een hele puntmap in de thuismap te verwijderen. Herbouw één project voordat je de Prullenmand leegt. Het doel is reproduceerbare uitvoer te verwijderen en de informatie te houden die nodig is om die opnieuw te maken.