# Svuotare le cache di sviluppo senza rompere le build > Preserva sorgenti, lockfile, accesso al registry e artefatti locali unici prima di potare gli store di pacchetti e gli alberi di dipendenze. Published: 2026-06-03 | Updated: 2026-08-08 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`](https://docs.npmjs.com/cli/commands/npm-cache); 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](https://doc.rust-lang.org/cargo/guide/cargo-home.html) 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`](https://pip.pypa.io/en/stable/cli/pip_cache/) la svuota. - **pnpm** e **yarn** tengono i propri store; `pnpm store prune` e [`yarn cache clean`](https://yarnpkg.com/cli/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](https://docs.gradle.org/current/userguide/directory_layout.html); 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.
A sinistra un store globale condiviso collegato con hard link in diversi progetti; a destra la stessa libreria copiata in ogni node_modules del progetto, duplicata
Uno store content-addressed condiviso e un albero di dipendenze materializzato per progetto hanno costi di storage diversi e confini di pulizia diversi.
## 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](https://mole.fit/) 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. --- Canonical HTML page: https://mole.fit/it/blog/how-to-clear-dev-caches-mac Blog index for agents: https://mole.fit/it/blog/llms.txt Site index for agents: https://mole.fit/llms.txt