# Perché Mole cancella meno cache rispetto a npm cache verify

> Un test su una copia della cache npm spiega cosa conservare, come Go elimina le voci inutilizzate e dove restano i file di compilazione.

Published: 2026-10-05

Di recente un utente mi ha scritto che la cache npm era rimasta dopo aver eseguito la manutenzione con Mole e che, pulendola da sé, era scesa da 8 GB a 2 GB. Ho quindi riesaminato le cache degli strumenti di sviluppo: quali file servono ancora, quali hanno perso i riferimenti e quali strumenti si occupano già della pulizia, senza bisogno che Mole faccia ricompilare tutto.

L'indagine e queste modifiche risalgono al 5 ottobre. Sono nel codice per una versione futura; la versione Preview attualmente disponibile non le include ancora.

## Perché la cache npm continua a crescere

La cache predefinita di npm è `~/.npm/_cacache`. `content-v2` conserva pacchetti e risposte del registro, mentre `index-v5` collega le richieste ai contenuti. I file prendono il nome dall'hash del contenuto e più voci possono riferirsi allo stesso file.

Quando cambiano i metadati di un pacchetto, npm scrive una nuova risposta. Le consultazioni successive possono rimuovere le vecchie voci dell'indice senza eliminare i file corrispondenti, lasciando contenuti senza riferimenti. Anche la [documentazione npm](https://docs.npmjs.com/cli/v11/commands/npm-cache/) spiega che la cache non elimina i dati da sola e cresce con le installazioni.

L'utente aveva già pulito la cache, quindi non avevo una copia precedente né la conferma del comando esatto. Il passaggio da 8 GB a 2 GB è l'origine dell'indagine, non una misura di 6 GB recuperati da Mole e nemmeno la prova che tutti quei dati fossero senza riferimenti.

## Che cosa ha eliminato verify in questo test

L'esperimento ha usato copie della cache di questo Mac con npm 11.19.1 e cacache 20.0.4. L'originale non è stato modificato. La cache aveva circa un giorno e conteneva 309796162 byte, non mesi di dati accumulati.

| Criterio | File di contenuto | Byte di contenuto |
| --- | --- | --- |
| Nessuna voce valida dell'indice rimanda a questi file | 1 | 614295 |
| Eliminati davvero da `npm cache verify` | 6 | 25469972 |

La differenza viene dall'[implementazione di verify in cacache](https://github.com/npm/cacache/blob/v20.0.4/lib/verify.js). Pulisce i contenuti, verifica l'integrità e ricostruisce l'indice conservando l'ultima voce per ogni chiave. Le voci precedenti possono però contenere metadati completi e abbreviati per richieste diverse, non semplicemente due versioni della stessa risposta.

Nella copia, 11199796 byte eliminati da verify erano ancora richiamati da voci valide di un'altra variante di richiesta. Alcune informazioni sui pacchetti leggibili offline prima della pulizia hanno poi restituito `ENOTCACHED` con `npm view` offline. Si potevano scaricare di nuovo online, ma il comportamento della cache era cambiato.

Mole adotta una regola più limitata: basta una voce valida dell'indice per conservare il contenuto. Trovare solo circa 0,6 MB in questo campione non giustifica eliminare una variante ancora utile per avvicinarsi al risultato di verify.

## Eliminare i file inutilizzati senza svuotare tutta la cache

La nuova implementazione esamina solo il percorso predefinito `~/.npm/_cacache`. I contenuti senza riferimenti più vecchi di un giorno compaiono in una riga selezionata per impostazione predefinita, nel gruppo degli strumenti di sviluppo. La rimozione dell'intera cache npm richiede ancora una verifica personale, e le selezioni sovrapposte contano gli stessi byte una sola volta.

Mentre comandi come `npm install` o `npm ci` scrivono nella cache, Mole non propone questi file per la pulizia. Se l’indice non è leggibile, i file restano fuori dall’elenco. I riferimenti vengono ricontrollati prima della rimozione; indice e cartelle temporanee non vengono modificati. Mole non esegue in background il comando di pulizia di npm.

Conservare i riferimenti dell'indice non garantisce che ogni progetto possa sempre essere compilato offline. Un file di lock può cercare un archivio direttamente tramite hash, e registri privati o versioni vecchie potrebbero non essere più disponibili. Sorgenti, file di lock e file che non si possono ricreare vanno conservati separatamente. I percorsi personalizzati della cache npm non rientrano in questa modifica.

## Go, Cargo e pnpm richiedono scelte diverse

Go pulisce già la propria cache di compilazione. La sua [implementazione](https://go.dev/src/cmd/go/internal/cache/cache.go) conserva le voci usate negli ultimi cinque giorni, con un'ora di margine aggiuntivo, cioè 121 ore. Mole prima proponeva l'intera cartella tra le pulizie preselezionate; ora segue la stessa regola temporale, conservando le voci recenti per evitare di doverle ricompilare.

Cargo dispone di [pulizia automatica della cache](https://doc.rust-lang.org/cargo/reference/config.html#cache), e in questo campione non c'erano contenuti scaduti. Una precedente eliminazione dei sorgenti estratti dal registro aveva portato, circa 29 ore dopo, a circa 157 MB scaricati e 1,06 GB decompressi. Mole non aggiunge un’altra pulizia automatica per quella cache; le voci esistenti, da selezionare dopo una verifica, restano disponibili.

Il deposito condiviso di pnpm è ancora diverso. Nel campione APFS analizzato, il numero di hard link non dimostrava che i file fossero inutilizzati; copiare quel criterio avrebbe selezionato l'intero deposito. Non è stata quindi aggiunta una pulizia automatica per pnpm. Per usare questo criterio, il numero di hard link deve indicare se un file è ancora in uso su quel file system.

## File di compilazione negli strumenti globali e nei vecchi progetti Xcode

Il `pake-cli` installato globalmente conteneva un `src-tauri/target` di circa 1,48 GiB: output Rust della compilazione Tauri, non cache di download npm. Queste cartelle con un `CACHEDIR.TAG` valido scritto dallo strumento vengono ora proposte per la verifica. Lo strumento installato e le sue dipendenze `node_modules` restano, e una compilazione Rust attiva impedisce di intervenire.

L'indagine ha trovato anche 24 cartelle Xcode DerivedData, circa 9 GiB, i cui percorsi di progetto registrati non esistevano più. Una cartella intera viene proposta solo se il progetto risulta assente sul disco di avvio e Xcode non usa quella cache da almeno due settimane. Un disco esterno scollegato o l'assenza di permessi di lettura non provano che il progetto sia stato eliminato. Queste dimensioni descrivono l'indagine, non promettono lo stesso recupero su ogni Mac; se serviranno ancora, ricreare gli output richiederà tempo.

## Prima capire quale livello si sta pulendo

Questo comando di sola lettura chiede a npm il percorso effettivo della cache, incluse le impostazioni personalizzate.

```bash
npm config get cache
```

Quando installazioni e compilazioni non stanno più scrivendo nella cache, si può decidere se eseguire `npm cache verify`. Modifica davvero la cache, non si limita a osservarla. Le cartelle `node_modules` dei progetti e i comandi globali sono elementi distinti che questo comando non elimina. La [guida alle cache di sviluppo](https://mole.fit/it/blog/how-to-clear-dev-caches-mac) descrive il percorso completo.

---

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