Vaciar cachés de desarrollo sin romper compilaciones

El almacenamiento de desarrollo se fragmenta entre descargas de paquetes, salidas de compilación, SDK, bases de datos locales y árboles de dependencias por proyecto. Algo es reproducible, algo depende de un lockfile y un registro que más adelante puede desaparecer, y algo es datos locales únicos. Una limpieza segura demuestra qué tipo encontró, en lugar de asumir que cada carpeta con punto es caché.

Las cachés globales, por herramienta

Cada gestor de paquetes mantiene un almacén global que puedes medir directamente:

du -sh ~/.npm ~/.cargo ~/.cache/pip ~/Library/Caches/pip ~/.gradle 2>/dev/null | sort -h

Estos son valores por defecto, no una promesa. Pregunta a la herramienta por su ruta configurada cuando sea posible; por ejemplo npm config get cache, python -m pip cache dir y pnpm store path.

• npm almacena las descargas en ~/.npm por defecto. Empieza con npm cache verify; npm describe su caché como auto-reparable, así que npm cache clean --force sirve sobre todo para recuperar espacio de forma deliberada o para diagnosticar.
• Cargo guarda registros y checkouts de git bajo ~/.cargo, pero el home de Cargo también puede contener binarios instalados, configuración, registros de paquetes y credenciales del registry. El Cargo actual elimina periódicamente entradas de caché global no usadas durante los comandos de build y fetch. Deja que esa política actúe, o inspecciona subdirectorios de caché concretos. Nunca elimines todo ~/.cargo.
• pip almacena wheels y respuestas HTTP en ~/Library/Caches/pip por defecto. python -m pip cache info informa su ubicación y tamaño reales, mientras que python -m pip cache purge la vacía.
• pnpm y yarn mantienen sus propios almacenes; pnpm store prune y yarn cache clean eliminan paquetes no referenciados o en caché. Revisa la versión activa del gestor de paquetes, porque el diseño del store y el comportamiento de caché local frente a global difieren.
• Gradle y Maven (~/.gradle, ~/.m2) pueden ser enormes en Macs de Android y JVM. Gradle ya realiza una limpieza periódica de caché; detén sus daemons antes de una revisión manual. Un repositorio de Maven puede contener artefactos locales o privados que no se pueden volver a descargar, así que inspéctalo en lugar de borrar el repositorio completo por defecto.

El coste puede incluir una descarga grande, una recompilación nativa o un build histórico fallido cuando una versión del registry ya no existe. Verifica el lockfile y el origen de cada dependencia antes de llamar reproducible a un store.

El problema de los node_modules dispersos

La sorpresa más grande no suele ser una sola caché, sino las carpetas node_modules repartidas en cada proyecto de JavaScript que hayas tocado. Cada una es autosuficiente y a menudo ocupa de 200 a 500 MB, así que diez proyectos antiguos pueden esconder varios gigabytes. Encuéntralas y mide su tamaño:

find ~/www ~/Projects -name node_modules -type d -prune -exec du -sh {} + 2>/dev/null

Sustituye las raíces de ejemplo por las carpetas donde guardas proyectos. -prune impide que find descienda en un árbol de dependencias ya coincidente, y -exec maneja de forma segura espacios y caracteres inusuales en las rutas. Un proyecto puede reconstruir sus dependencias solo cuando su código fuente, lockfile, versión del gestor de paquetes, acceso al registry y la toolchain nativa necesaria siguen disponibles. Prefiere el comando específico del lockfile, como npm ci, después de preservar esas entradas.

No borres esto

Las cachés de paquetes pueden ser reemplazables, pero dos vecinos no lo son. El código fuente y los lockfiles del proyecto (package.json, package-lock.json, Cargo.lock) no son caché: definen el build, así que nunca los barres. Y un store global que estés usando de forma activa, como un store de pnpm con direccionamiento por contenido compartido entre proyectos, solo se volverá a descargar, pero borrarlo a mitad de una instalación puede corromperlo; limpia las cachés cuando no haya nada compilando.

Bajo el capó: stores con direccionamiento por contenido, y por qué node_modules es la excepción

Muchos gestores de paquetes usan stores con direccionamiento por contenido para reducir descargas repetidas. pnpm mantiene un store global de cada versión de paquete y los enlaza con hard links en el node_modules de cada proyecto, de modo que diez proyectos que usan la misma librería comparten una sola copia en disco. Las cachés de Cargo y Go también indexan el contenido descargado por versión o checksum. Eso protege la integridad, pero no garantiza disponibilidad futura. Una instalación convencional de npm materializa un árbol de dependencias por proyecto, mientras que pnpm puede enlazar proyectos a un store compartido. Por eso borrar un directorio node_modules y hacer prune de un store compartido tienen radios de impacto diferentes.

Usa mapas para descubrir, gestores de paquetes para limpiar

La naturaleza dispersa es el problema de descubrimiento. Un treemap como la vista Analyze de Mole puede revelar qué proyecto o store es grande, pero el comando propio de verify, prune o clean del gestor de paquetes entiende su índice y sus referencias. Usa el mapa para elegir un objetivo y la herramienta propietaria para cambiarlo.

Un orden seguro de operaciones

Detén builds y daemons, mide las raíces de proyecto seleccionadas, verifica los stores de los gestores de paquetes y conserva el código fuente más los lockfiles antes de eliminar un árbol de dependencias. Usa comandos de prune documentados en lugar de borrar una carpeta con punto entera del home. Reconstruye un proyecto antes de vaciar la Papelera. El objetivo es quitar salidas reproducibles y conservar la información necesaria para volver a producirlas.