¿La caché de npm y node_modules ocupando espacio en Mac? Que hacer de forma segura

Por qué la caché de npm y node_modules crecen tan rápido en Mac

Las máquinas de desarrollador JavaScript rara vez crecen por un solo proyecto. El patrón real es acumulación.

Instalas paquetes a través de múltiples apps, branches, prototipos y repos de clientes. npm mantiene una caché reutilizable para que las instalaciones no necesiten descargar todo desde cero cada vez. Cada proyecto también mantiene su propio árbol de dependencias local en node_modules.

Eso significa que el crecimiento de disco puede venir de dos direcciones a la vez:

• una caché compartida de npm que sigue expandiéndose a medida que instalas nuevos paquetes y versiones;
• múltiples carpetas de proyecto, cada una con su propio árbol node_modules;
• dependencias duplicadas o casi duplicadas a través de repos antiguos;
• módulos nativos y paquetes de toolchain que agregan costo de rebuild incluso cuando son técnicamente desechables;
• proyectos stale que nunca se archivaron, eliminaron o reinstalaron limpiamente.

El resultado es familiar: un repo es molesto, diez repos son costosos, y un año de trabajo normal se convierte en un silencioso problema de almacenamiento.

Caché de npm vs node_modules: ¿Cuál es la diferencia?

Esta es la distinción que más importa.

Según los docs oficiales de npm, los archivos de caché viven en ~/.npm en sistemas Posix por defecto, mientras que las instalaciones locales van a ./node_modules bajo la raíz del paquete actual. npm carga paquetes en la caché primero, luego los desempaqueta en node_modules para el proyecto que los necesita.

Por eso “npm está ocupando espacio” suele ser demasiado vago para ser accionable. Necesitas saber si la presión viene de la caché compartida, instalaciones de proyectos antiguos, o ambos.

Qué implican los propios docs de npm

La caché de npm está diseñada como caché, no como el árbol de dependencias funcional de tu proyecto. npm la documenta explícitamente como una caché que se puede repoblar después.

node_modules es diferente. Esa carpeta es donde viven realmente los paquetes, ejecutables y grafo de dependencias locales de tu proyecto. Si la eliminas, no estas solo limpiando una caché. Estás removiendo las dependencias instaladas que el proyecto usa actualmente.

¿Es seguro eliminar la caché de npm en Mac?

Normalmente si, pero la razón importa.

Los docs oficiales de npm dicen que la caché está verificada por integridad y que limpiarla generalmente solo debería ser necesaria cuando el objetivo es recuperar espacio en disco. Esa es una diferencia de enfoque importante. La caché de npm no debería tratarse como estado precioso, pero tampoco es algo que necesites limpiar rutinariamente solo porque existe.

El modelo mental seguro es:

• si tu Mac está ajustada de espacio, la limpieza de caché puede ser un tradeoff razonable;
• si tus instalaciones funcionan normalmente, limpiar la caché suele ser innecesario;
• si la limpias, espera que instalaciones posteriores descarguen paquetes de nuevo;
• si solo quieres verificar el estado de la caché primero, usa npm cache verify.

Mejor primer movimiento: verificar antes de limpiar

npm documenta npm cache verify como el paso de verificación offline para contenidos de caché existentes. Eso lo convierte en el mejor primer comando cuando quieres una verificación de menor riesgo antes de recuperar espacio.

npm cache verify

Si tu objetivo es específicamente liberar espacio, el comando de limpieza documentado de npm es:

npm cache clean --force

El flag --force es requerido por diseño. npm trata la limpieza de caché como una decisión intencional de espacio en disco, no como un hábito de mantenimiento cotidiano.

¿Es seguro eliminar node_modules en Mac?

A veces, pero aquí es donde el contexto importa mucho más.

Eliminar node_modules remueve el árbol de dependencias local para ese proyecto. Si el proyecto esta activo, la consecuencia inmediata suele ser obvia: los scripts dejan de encontrar paquetes, los binarios locales desaparecen de node_modules/.bin y la próxima instalación o build puede tomar más tiempo del que quisieras.

Eso no significa que nunca deberías eliminarlo. Significa que deberías hacerlo deliberadamente.

Buenos candidatos para eliminar node_modules:

• un proyecto antiguo que ya no ejecutas activamente;
• una demo o prototipo stale que puedes reconstruir después;
• un repo que vas a reinstalar limpiamente de todas formas;
• un proyecto con un lockfile confiable donde la reinstalacion es esperada y aceptable.

Situaciones de mayor fricción:

• un repo de trabajo activo justo antes de un deadline, demo o build de release;
• un proyecto con módulos nativos que toman tiempo en reconstruir;
• un workspace que no has tocado en meses y puede que no recuerdes como restaurar rápidamente;
• un repo sin una historia de dependencias limpia o sin el lockfile que esperas.

Por qué las carpetas node_modules antiguas dolen tanto

Un proyecto puede ser manejable. El verdadero desperdicio viene de tener muchos de ellos.

Cada repo antiguo puede mantener un árbol de dependencias completo, metadatos del gestor de paquetes, paquetes nativos opcionales, toolchains de framework y artefactos específicos por versión. Por eso los desarrolladores a menudo piensan que npm es el problema cuando el mayor culpable es realmente una pila de carpetas node_modules olvidadas en repos retirados.

Cómo limpiar la caché de npm manualmente

Si quieres la ruta manual, manténla estrecha y explícita.

1. Verifica el directorio de caché activo

Si cambiaste la configuración de npm en algún momento, tu caché puede no estar en la ubicación por defecto. Pregunta a npm primero:

npm config get cache

2. Verifica la caché antes de eliminarla

Usa el paso de verificación documentado primero:

npm cache verify

3. Limpia la caché solo si realmente quieres recuperar el espacio

Si recuperar espacio en disco vale las redescargas posteriores:

npm cache clean --force

4. Vuelve a verificar el tamaño si es necesario

Una vez que conozcas la ruta de la caché, puedes inspeccionar su tamaño directamente:

du -sh "$(npm config get cache)"

Esta es la secuencia más segura porque separa ubicación, verificación y limpieza en decisiones distintas.

Cómo encontrar carpetas node_modules antiguas antes de eliminar nada

Esta suele ser la pasada de limpieza de mayor valor.

Empieza con los proyectos que ya no compilas activamente. Eso importa más que perseguir la carpeta más grande en Finder sin contexto.

Usa un orden de revisión como este:

1. Busca carpetas node_modules en tu directorio principal de proyectos.
2. Verifica que repos están stale, archivados o fáciles de reinstalar.
3. Confirma si el proyecto todavía necesita ejecutarse localmente esta semana.
4. Elimina solo las carpetas node_modules cuyo costo de rebuild entiendas.

Si quieres una revisión asistida por Terminal, usa comandos que te muestren donde están esas carpetas antes de eliminar nada:

find ~/Projects -type d -name node_modules -prune -print
find ~/Projects -type d -name node_modules -prune -exec du -sh {} +

Eso sigue siendo manual, pero es mejor que reaccionar emocionalmente a una carpeta de trabajo enorme.

Qué revisar antes de eliminar node_modules de un proyecto

• ¿El repo sigue activo?
• ¿Tienes el lockfile que esperas?
• ¿Hay módulos nativos o pasos de codegen que hacen la reinstalacion más lenta?
• ¿El proyecto es parte de un setup de monorepo o workspace que no quieres perturbar casualmente?
• ¿Seria archivar o eliminar todo el proyecto retirado un mejor movimiento de limpieza que solo remover node_modules?

A menudo la acción de limpieza más fuerte no es “limpia dependencias en todos lados.” Es “elimina el proyecto antiguo que ya no necesitas.”

¿Qué pasa con las cachés de yarn, pnpm y bun?

Mantén esta parte separada de npm.

Si el proyecto usa otro gestor de paquetes, usa el propio modelo de limpieza de ese gestor en vez de asumir que los comandos de npm aplican limpiamente.

Yarn

Yarn moderno documenta yarn cache clean como el comando que remueve archivos de caché compartidos. También expone --mirror y --all para alcances de limpieza más amplios.

yarn cache clean

pnpm

pnpm usa un modelo de store en vez del patrón exacto de caché de npm. Los docs oficiales de pnpm describen pnpm store prune como la eliminación de paquetes sin referencia del store y notan que futuras instalaciones pueden descargar paquetes eliminados de nuevo cuando se necesiten.

pnpm store prune

Bun

Bun documenta una caché de paquetes global en ~/.bun/install/cache por defecto. Sus docs también notan que los paquetes todavía se copian en node_modules después de la descarga, así que Bun puede crear la misma confusión de “caché más instalación de proyecto” si solo miras el tamaño de la carpeta.

Lo importante no es memorizar cada comando. Es evitar mezclar modelos de almacenamiento. La caché de npm, la caché de Yarn, el store de pnpm y la caché de Bun son problemas relacionados, no idénticos.

Por qué la limpieza de desarrollador es más segura cuando revisas por ecosistema

node_modules rara vez es el único problema de almacenamiento de desarrollador en un Mac. Suele estar junto a datos de Xcode, almacenamiento de simuladores, imágenes de Docker, caché de build, logs y otras rutas específicas de toolchain.

Un navegador de archivos plano muestra que una carpeta es grande. No te dice si es:

• una caché de npm reconstruible;
• un árbol de dependencias de workspace activo;
• un store de pnpm;
• una caché de Docker;
• o un ecosistema diferente que solo vive cerca de tus proyectos.

Por eso la limpieza de desarrollador funciona mejor cuando el flujo se mantiene consciente del ecosistema.

Si tu situación real es “npm más Docker más datos antiguos de Xcode más demasiados repos stale,” ese modelo más amplio de revisión primero es más útil que perseguir una carpeta a la vez.

Conclusión

Si la caché de npm y node_modules están ocupando espacio en tu Mac, no los trates como el mismo objetivo de limpieza.

Usa npm cache verify y, cuando recuperar espacio sea el objetivo real, npm cache clean --force para la caché compartida. Revisa las carpetas node_modules antiguas proyecto por proyecto y eliminalas solo cuando entiendas el costo de reinstalacion.

Ese es el camino más seguro: separa la caché del estado del workspace, revisa proyectos stale antes que los activos y mantén la limpieza de desarrollador vinculada al contexto del ecosistema en vez de eliminación ciega de carpetas.