Où part vraiment le disque d'un développeur
Les quatre gros accumulationneurs surprennent rarement celui qui a regardé une fois : les caches de paquets grandissent sans plafond parce que c'est le réglage par défaut, node_modules duplique l'arbre de dépendances dans chaque projet, Docker conserve chaque couche jamais téléchargée ou construite, et WSL2 range tout le système de fichiers Linux dans un disque virtuel qui grossit à la demande et ne rétrécit jamais de lui-même. Ajoutez les index d'IDE, les artefacts de build et trois versions de SDK côte à côte — une machine de deux ans transporte tranquillement des dizaines de gigaoctets de lest mort avéré. Il n'y a aucun mystère : les déchets sont juste étalés sur une douzaine de répertoires où vous ne regardez jamais.
- npm : %LOCALAPPDATA%\npm-cache — des copies complètes de chaque version de chaque paquet déjà installé
- pip : %LOCALAPPDATA%\pip\cache — des wheels de tout et n'importe quoi, plus ~/.cache/pip dans chaque distribution WSL
- Docker Desktop : images fantômes, conteneurs arrêtés, cache de build et volumes anonymes — docker system df donne le total, docker system prune le récupère
- WSL2 : le fichier de distribution ext4.vhdx grossit à chaque build et ne rend jamais de place sans compactage forcé
- Projets : le node_modules d'un dépôt abandonné pèse de quelques centaines de Mo à plusieurs Go — la valeur est dans le lockfile, le dossier se reconstruit
- IDE : les répertoires de cache et d'index JetBrains, plus les dossiers target/, build/, dist/, obj/ éparpillés sur tous les checkouts
La passe trimestrielle, dans le bon ordre
Mesurez d'abord, pour que l'heure aille là où est la masse : un outil treemap sur le profil utilisateur, docker system df pour le côté conteneurs, wsl --list --verbose pour les distributions. Ensuite, allez du sûr au risqué : les caches se reconstruisent à la demande, donc purgez-les librement — npm cache clean --force, pip cache purge et leurs équivalents Gradle et cargo ; viennent ensuite les projets abandonnés — supprimez les dossiers de dépendances, gardez les lockfiles, et quand le dépôt se réveille, npm ci ou pip install -r reconstruit tout en quelques minutes. Après, Docker : poussez dehors les images fantômes et le cache de build, gardez les images étiquetées que vous lancez vraiment. En dernier, le disque virtuel WSL2, parce que supprimer à l'intérieur de la distribution ne rétrécit pas le fichier côté Windows : lancez wsl --shutdown, puis compactez le vhdx — ou exportez et réimportez la distribution si elle a pris une taille vraiment monstrueuse.
Les habitudes qui gardent le disque plat
L'hygiène en habitude coûte moins cher que l'hygiène en sauvetage. Gardez les outils par projet plutôt qu'en installations globales, laissez la CI tirer les images au lieu de les thésauriser localement, et lancez docker system prune chaque mois avant que le zoo de couches ne développe une mémoire. Mettez les datasets de plusieurs gigaoctets sur un second disque et faites un lien — le disque système ne garde alors que ce qui se régénère. Et traitez un C: presque plein comme un incident de build, pas comme de la cosmétique : npm, Docker et la chaîne de compilation se mettent à échouer des manières les plus inventives quand leur disque de travail déborde.
Questions et réponses
Est-il sûr de supprimer les caches npm et pip ?
Oui — les caches sont faits pour se reconstruire. npm cache clean --force et pip cache purge libèrent la place, et la prochaine installation retélécharge simplement ce dont elle a besoin.
Comment réduire le disque virtuel WSL2 ?
Supprimez d'abord les déchets à l'intérieur de la distribution, puis lancez wsl --shutdown et compressez le vhdx avec DiskPart ou Optimize-VHD. Pour une distribution vraiment ballonnée : export puis réimport — le fichier neuf ne contient que des données vivantes.
Vérifiez le contenu avant l'achat.
L'essai unique de 30 minutes couvre les fonctions de base. Les fonctions marquées PRO restent verrouillées jusqu'à l'activation d'une licence payante.
À lire ensuite
Écrivez-nous: [email protected]