Svuotare le cache di sviluppo senza rompere le build

Lo storage di sviluppo è frammentato tra download dei pacchetti, output di build, SDK, database locali e alberi di dipendenze per progetto. Una parte è riproducibile, un'altra dipende da un lockfile e da un registry che in seguito può sparire, e un'altra ancora è dati locali unici. Una pulizia sicura dimostra di che tipo si tratta, invece di assumere che ogni cartella con il punto sia cache.

Le cache globali, per strumento

Ogni package manager tiene uno store globale che puoi misurare direttamente:

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

Questi sono i percorsi predefiniti, non una garanzia. Quando possibile, chiedi allo strumento il percorso configurato, per esempio npm config get cache, python -m pip cache dir e pnpm store path.

• npm mette in cache i download in ~/.npm per impostazione predefinita. Inizia con npm cache verify; npm descrive la sua cache come self-healing, quindi npm cache clean --force serve soprattutto a recuperare spazio in modo deliberato o a risolvere problemi.
• Cargo tiene registry e checkout git sotto ~/.cargo, ma la home di Cargo può contenere anche binari installati, configurazione, record dei pacchetti e credenziali del registry. Le versioni attuali di Cargo rimuovono periodicamente le voci di cache globale non usate durante i comandi di build e fetch. Lascia lavorare questa policy, oppure ispeziona le sottocartelle esatte della cache. Non rimuovere mai l'intera ~/.cargo.
• pip mette in cache wheel e risposte HTTP in ~/Library/Caches/pip per impostazione predefinita. python -m pip cache info riporta la posizione e le dimensioni effettive, mentre python -m pip cache purge la svuota.
• pnpm e yarn tengono i propri store; pnpm store prune e yarn cache clean eliminano i pacchetti non referenziati o in cache. Controlla la versione attiva del package manager, perché il layout dello store e il comportamento della cache locale rispetto a quella globale differiscono.
• Gradle e Maven (~/.gradle, ~/.m2) possono diventare enormi sui Mac usati per Android e JVM. Gradle esegue già una pulizia periodica della cache; interrompi i suoi daemon prima di una revisione manuale. Un repository Maven può contenere artefatti costruiti in locale o privati che non si possono scaricare di nuovo, quindi ispezionalo invece di eliminare l'intero repository per impostazione predefinita.

Il costo può includere un download pesante, una rebuild nativa o un fallimento di una build storica quando una versione del registry non c'è più. Verifica il lockfile e la fonte di ogni dipendenza prima di considerare uno store riproducibile.

Il problema dei node_modules sparsi

La sorpresa più grande di solito non è una singola cache, ma le cartelle node_modules sparse in ogni progetto JavaScript che hai mai toccato. Ognuna è autonoma e spesso pesa da 200 a 500 MB, quindi dieci progetti vecchi possono nascondere diversi gigabyte. Trovale e le relative dimensioni:

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

Sostituisci le root di esempio con le cartelle in cui tieni i progetti. -prune impedisce a find di scendere nell'albero di dipendenze trovato, e -exec gestisce in modo sicuro spazi e caratteri insoliti nei percorsi. Un progetto può ricostruire le dipendenze solo se sorgente, lockfile, versione del package manager, accesso al registry e toolchain nativa richiesta sono ancora disponibili. Preferisci il comando specifico per il lockfile, come npm ci, dopo aver preservato questi input.

Non eliminare questi elementi

Le cache dei pacchetti possono essere sostituibili, ma due vicini no. Il sorgente e i lockfile del progetto (package.json, package-lock.json, Cargo.lock) non sono cache: definiscono la build, quindi non spazzarli mai. E uno store globale che stai usando attivamente, come uno store content-addressed di pnpm condiviso tra progetti, verrà semplicemente riscaricato, ma una cancellazione a metà installazione può corromperlo: svuota le cache quando non c'è nulla in build.

Dietro le quinte: store content-addressed e perché node_modules è l'eccezione

Molti package manager usano store content-addressed per ridurre i download ripetuti. pnpm tiene uno store globale di ogni versione di pacchetto e le collega con hard link nel node_modules di ogni progetto, così dieci progetti che usano la stessa libreria condividono una sola copia su disco. Anche le cache di Cargo e Go indicizzano il contenuto scaricato per versione o checksum. Questo tutela l'integrità, ma non garantisce la disponibilità futura. Un'installazione npm convenzionale materializza un albero di dipendenze per progetto, mentre pnpm può collegare i progetti a uno store condiviso. Ecco perché eliminare una cartella node_modules e fare il prune di uno store condiviso hanno raggio d'impatto diverso.

Usa le mappe per scoprire, i package manager per pulire

La natura sparsa è il problema di discovery. Una treemap come la vista Analyze di Mole può mostrare quale progetto o store è grande, ma il comando di verify, prune o clean del package manager stesso conosce il suo indice e i riferimenti. Usa la mappa per scegliere un obiettivo e lo strumento proprietario per modificarlo.

Un ordine di operazioni sicuro

Ferma build e daemon, misura le root di progetto selezionate, verifica gli store dei package manager e preserva sorgente più lockfile prima di rimuovere un albero di dipendenze. Usa i comandi di prune documentati invece di eliminare un'intera cartella con il punto nella home. Ricostruisci un progetto prima di svuotare il Cestino. L'obiettivo è rimuovere l'output riproducibile mantenendo le informazioni necessarie per riprodurlo.