Dove va davvero il disco di uno sviluppatore
I quattro grandi accumulatori sorprendono raramente chi ci ha guardato una volta: le cache dei pacchetti crescono senza tetto perché è quello il default, node_modules duplica l'albero delle dipendenze in ogni progetto, Docker tiene ogni layer che abbia mai scaricato o costruito, e WSL2 custodisce l'intero filesystem Linux in un disco virtuale che cresce a domanda e non si restringe mai da solo. Aggiungete gli indici degli IDE, gli artefatti di build e tre versioni di SDK fianco a fianco: una macchina di due anni porta con noncuranza decine di gigabyte di zavorra dimostrabilmente morta. Niente di misterioso — la spazzatura è semplicemente sparsa in una dozzina di directory che non visitate mai.
- npm: %LOCALAPPDATA%\npm-cache — copie integrali di ogni versione di ogni pacchetto che avete mai installato
- pip: %LOCALAPPDATA%\pip\cache — wheel di tutto, più ~/.cache/pip dentro ogni distro WSL
- Docker Desktop: immagini dangling, container fermi, cache di build e volumi anonimi — docker system df mostra il totale, docker system prune lo recupera
- WSL2: il file ext4.vhdx della distro cresce a ogni build e non restituisce mai lo spazio senza un compact forzato
- Progetti: lo node_modules di un repo abbandonato va da centinaia di MB a diversi GB — il valore sta nel lockfile, la cartella si ricostruisce
- IDE: le directory di cache e indici di JetBrains, più le cartelle target/, build/, dist/, obj/ sparse in ogni checkout
Il passaggio trimestrale, nell'ordine giusto
Prima misurate, così l'ora va dove sta la massa: uno strumento treemap sul profilo utente, docker system df per il lato container, wsl --list --verbose per le distro. Poi dal sicuro al rischioso: le cache si ricostruiscono a domanda, quindi svuotatele senza timore — npm cache clean --force, pip cache purge e gli equivalenti in Gradle e cargo; poi i progetti abbandonati — eliminate le cartelle delle dipendenze, tenete i lockfile, e quando il repo si risveglia, npm ci o pip install -r ricostruisce tutto in minuti. Docker viene dopo: potate le immagini dangling e la cache di build, tenete le immagini taggate che eseguite davvero. Per ultimo il disco virtuale WSL2, perché le eliminazioni dentro la distro non restringono il file lato Windows: eseguite wsl --shutdown, poi compattate il vhdx — oppure esportate e re-importate la distro se è cresciuta davvero mostruosamente.
Le abitudini che tengono il disco piatto
L'igiene come abitudine costa meno dell'igiene come soccorso. Tenete il tooling per progetto invece delle installazioni globali, lasciate che la CI scarichi immagini fresche invece di accaparrarvele in locale, e eseguite docker system prune ogni mese prima che lo zoo di layer faccia in tempo a farsi memoria. Mettete i dataset da multi-gigabyte su un secondo disco e linkateli, così il disco di sistema tiene solo ciò che si rigenera. E trattate una C: quasi piena come un incidente di build, non come un dettaglio estetico: npm, Docker e la toolchain del compilatore cominciano a fallire in modi creativi quando finisce il disco su cui grattano.
Domande e risposte
È sicuro cancellare le cache di npm e pip?
Sì — le cache esistono per essere ricostruite. npm cache clean --force e pip cache purge liberano lo spazio, e l'installazione successiva si limita a riscaricare ciò che serve.
Come riduco il disco virtuale WSL2?
Prima eliminate la spazzatura dentro la distro, poi eseguite wsl --shutdown e compattate il vhdx con DiskPart o Optimize-VHD. Per una distro davvero gonfia: esportazione e re-importazione — il file fresco contiene solo i dati vivi.
Scopri cosa include la licenza prima dell'acquisto.
La prova singola di 30 minuti include gli strumenti essenziali. Le funzioni PRO restano bloccate finché non attivi una licenza a pagamento.
Da leggere dopo
Scrivici: [email protected]