# Vaciar cachés de desarrollo sin romper compilaciones > Conserva el código fuente, los lockfiles, el acceso al registro y artefactos locales únicos antes de podar almacenes de paquetes y árboles de dependencias. Published: 2026-06-03 | Updated: 2026-08-08 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`](https://docs.npmjs.com/cli/commands/npm-cache); 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](https://doc.rust-lang.org/cargo/guide/cargo-home.html) 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`](https://pip.pypa.io/en/stable/cli/pip_cache/) la vacía. - **pnpm** y **yarn** mantienen sus propios almacenes; `pnpm store prune` y [`yarn cache clean`](https://yarnpkg.com/cli/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é](https://docs.gradle.org/current/userguide/directory_layout.html); 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.
A la izquierda un almacén global compartido enlazado por hard link en varios proyectos; a la derecha la misma biblioteca copiada en el node_modules de cada proyecto, duplicada
Un store compartido con direccionamiento por contenido y un árbol de dependencias materializado por proyecto tienen costes de almacenamiento y límites de limpieza distintos.
## 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](https://mole.fit/) 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. --- Canonical HTML page: https://mole.fit/es/blog/how-to-clear-dev-caches-mac Blog index for agents: https://mole.fit/es/blog/llms.txt Site index for agents: https://mole.fit/llms.txt