Por qué Mole borra menos caché que npm cache verify

Hace poco un usuario me contó que la caché de npm seguía ahí después de una pasada de mantenimiento con Mole y que, al limpiarla por su cuenta, bajó de 8 GB a 2 GB. Eso me llevó a revisar las cachés de desarrollo: qué archivos aún se usan, cuáles han perdido sus referencias y qué herramientas ya se encargan de limpiarse, para no hacer más lenta la siguiente compilación.

La investigación y estos cambios son del 5 de octubre. Están en el código para una versión futura; la versión Preview disponible todavía no los incluye.

Por qué la caché de npm sigue creciendo

La caché predeterminada de npm está en ~/.npm/_cacache. content-v2 guarda paquetes y respuestas del registro, mientras que index-v5 relaciona las peticiones con ese contenido. Los archivos llevan el hash de su contenido y varias entradas pueden apuntar al mismo archivo.

Cuando cambian los metadatos de un paquete, npm escribe una respuesta nueva. Las consultas posteriores pueden quitar entradas antiguas del índice sin borrar sus archivos, y así queda contenido sin referencias. La documentación de npm también explica que la caché no elimina datos por sí sola y crece con las instalaciones.

El usuario ya había limpiado la caché, así que no tenía una copia anterior ni confirmación del comando exacto. La reducción de 8 GB a 2 GB inició la investigación; no mide 6 GB recuperados por Mole ni demuestra que todos esos datos carecieran de referencias.

Qué borró verify en esta prueba

El experimento usó copias de la caché de este Mac con npm 11.19.1 y cacache 20.0.4. El original no se modificó. La caché tenía alrededor de un día y 309796162 bytes de contenido, no varios meses de acumulación.

La diferencia está en la implementación de verify en cacache. Limpia contenido, comprueba la integridad y reconstruye el índice, conservando la última entrada de cada clave. Las anteriores aún pueden guardar metadatos completos y abreviados para peticiones distintas; no son simplemente versiones viejas y nuevas de una misma respuesta.

En la copia, 11199796 bytes borrados por verify seguían referenciados por entradas válidas de otra variante de petición. Parte de la información de paquetes que se podía leer sin conexión antes devolvió después ENOTCACHED al ejecutar npm view sin conexión. Se podía descargar de nuevo, pero la caché ya se comportaba de otra manera.

Mole aplica una regla más limitada: basta una entrada válida del índice para conservar su contenido. Encontrar solo unos 0,6 MB en esta muestra no justifica borrar una variante útil para acercarse a la cifra de verify.

Borrar archivos sin uso sin vaciar toda la caché

La nueva implementación solo examina la ruta predeterminada ~/.npm/_cacache. El contenido sin referencias de más de un día aparece en una fila seleccionada por defecto dentro del grupo de herramientas de desarrollo. Borrar toda la caché de npm sigue requiriendo revisión, y las selecciones que se solapan cuentan sus bytes una sola vez.

Mientras comandos como npm install o npm ci escriben en la caché, Mole no incluye estos archivos en la lista de limpieza. Si no puede leer el índice, tampoco los ofrece para borrar. Las referencias se comprueban de nuevo antes del borrado; los archivos del índice y los directorios temporales quedan intactos. Mole no ejecuta la limpieza de npm en segundo plano.

Conservar referencias del índice no garantiza que todos los proyectos puedan compilarse siempre sin conexión. Un archivo de bloqueo puede buscar un paquete directamente por su hash, y los registros privados o las versiones antiguas quizá no sigan disponibles. El código fuente, los archivos de bloqueo y los archivos que no se puedan volver a generar necesitan conservarse por separado. Las rutas personalizadas de caché npm quedan fuera de este cambio.

Go, Cargo y pnpm necesitan decisiones distintas

Go ya limpia su caché de compilación. Su implementación conserva las entradas usadas en los últimos cinco días, con una hora extra de margen: 121 horas. Mole antes incluía el directorio completo en la limpieza seleccionada por defecto; ahora lo limita a la misma regla temporal, conservando las entradas recientes para evitar tener que recompilarlas.

Cargo cuenta con limpieza automática de la caché, y en esta muestra no había contenido vencido. Tras una eliminación anterior de las fuentes extraídas del registro, unas 29 horas después se descargaron aproximadamente 157 MB y se descomprimieron 1,06 GB. Mole no añade otra limpieza automática para ese almacenamiento; las opciones existentes que requieren revisión manual siguen disponibles.

El almacén compartido de pnpm es diferente. En la muestra APFS analizada, el número de enlaces duros no demostraba que los archivos estuvieran sin usar; copiar ese criterio habría seleccionado todo el almacén. Por eso no se añadió una limpieza automática para pnpm. Para usar ese criterio, el número de enlaces duros tendría que indicar si un archivo sigue en uso en ese sistema de archivos.

Archivos de compilación en herramientas globales y antiguos proyectos Xcode

El pake-cli instalado globalmente tenía un src-tauri/target de unos 1,48 GiB: salida de Rust al compilar Tauri, no la caché de descargas de npm. Estos directorios con un CACHEDIR.TAG válido escrito por la herramienta se ofrecen ahora para revisión. La herramienta instalada y sus dependencias node_modules se conservan, y estos directorios no se ofrecen mientras hay una compilación de Rust en curso.

La investigación también encontró 24 directorios Xcode DerivedData, unos 9 GiB, cuyos proyectos ya no existían en las rutas registradas. Solo se ofrece un directorio entero cuando se confirma la ausencia del proyecto en el disco de arranque y Xcode no ha usado esa caché durante al menos dos semanas. Un disco externo desconectado o la falta de permiso de lectura no demuestran que un proyecto se haya borrado. Son tamaños de aquella investigación, no un ahorro prometido en todos los Mac; volver a generar los archivos también lleva tiempo.

Comprobar qué capa se va a limpiar

Este comando de solo lectura pide a npm la ubicación real de su caché, incluida una ruta personalizada.

npm config get cache

Cuando las instalaciones y compilaciones hayan dejado de escribir en esa caché, se puede decidir si ejecutar npm cache verify. Modifica la caché, no es solo una consulta. Los node_modules de los proyectos y los comandos globales se gestionan por separado y este comando no los limpia. La guía de cachés de desarrollo explica el recorrido completo.