A dónde va realmente el disco de un desarrollador
Los cuatro grandes acaparadores rara vez sorprenden a quien ha mirado una vez: las cachés de paquetes crecen sin techo porque así viene por defecto, node_modules duplica el árbol de dependencias en cada proyecto, Docker conserva cada capa que descargó o construyó, y WSL2 guarda todo el sistema de archivos Linux en un disco virtual que crece a demanda y jamás se encoge solo. Súmale los índices del IDE, los artefactos de compilación y tres versiones del SDK una al lado de la otra — una máquina de dos años carga sin esfuerzo decenas de gigabytes de lastre muerto comprobado. No hay misterio: la basura solo está repartida entre una docena de directorios a los que nunca entras.
- npm: %LOCALAPPDATA%\npm-cache — copias completas de cada versión de cada paquete que instalaste alguna vez
- pip: %LOCALAPPDATA%\pip\cache — wheels de todo lo habido, más ~/.cache/pip dentro de cada distribución WSL
- Docker Desktop: imágenes colgantes, contenedores parados, caché de build y volúmenes anónimos — docker system df da el total, docker system prune lo reclama
- WSL2: el archivo de distribución ext4.vhdx crece con cada build y no devuelve espacio sin un compactado a la fuerza
- Proyectos: el node_modules de un repo abandonado pesa de cientos de MB a varios GB — el valor está en el lockfile, la carpeta se reconstruye
- IDEs: los directorios de caché e índices de JetBrains, más las carpetas target/, build/, dist/, obj/ regadas por todos los checkouts
La pasada trimestral, en el orden correcto
Mide primero, para que la hora se vaya a donde está la masa: una herramienta treemap sobre el perfil de usuario, docker system df para el lado contenedores, wsl --list --verbose para las distribuciones. Después trabaja de lo seguro a lo arriesgado: las cachés se reconstruyen bajo demanda, así que purga sin miedo — npm cache clean --force, pip cache purge y sus equivalentes en Gradle y cargo; siguen los proyectos abandonados — borra las carpetas de dependencias, conserva los lockfiles, y cuando el repo despierte, npm ci o pip install -r lo reconstruye en minutos. Después Docker: fuera imágenes colgantes y caché de build, y se quedan las imágenes etiquetadas que de verdad ejecutas. Al final, el disco virtual de WSL2, porque borrar dentro de la distribución no encoge el archivo en el lado de Windows: ejecuta wsl --shutdown y compacta el vhdx — o exporta y reimporta la distribución si ha crecido hasta lo monstruoso.
Hábitos que mantienen el disco plano
La higiene como hábito sale más barata que como rescate. Mantén las herramientas por proyecto en vez de en instalaciones globales, deja que el CI baje las imágenes en vez de acapararlas localmente, y pasa docker system prune cada mes antes de que el zoológico de capas desarrolle memoria. Los datasets de varios gigabytes, a un segundo disco con un enlace — al disco del sistema le queda solo lo que se regenera. Y trata un C: casi lleno como un incidente de compilación, no como cosmética: npm, Docker y la cadena de compilación empiezan a fallar de las maneras más inventivas cuando se les acaba el sitio donde rascarse.
Preguntas y respuestas
¿Es seguro borrar las cachés de npm y pip?
Sí — las cachés existen para reconstruirse. npm cache clean --force y pip cache purge liberan el espacio, y la siguiente instalación simplemente vuelve a descargar lo que necesita.
¿Cómo reduzco el disco virtual de WSL2?
Borra primero la basura dentro de la distribución, luego ejecuta wsl --shutdown y compacta el vhdx con DiskPart u Optimize-VHD. Para una distribución realmente hinchada: exportar y reimportar — el archivo nuevo solo contiene datos vivos.
Consulta qué incluye antes de comprar.
La prueba única de 30 minutos incluye las funciones básicas. Las funciones marcadas PRO permanecen bloqueadas hasta activar una licencia de pago.
Sigue leyendo
Escríbenos: [email protected]