--- title: "Cómo Actualizar Todas las Dependencias de Node.js a la Última Versión" description: "Aprende a actualizar todas las dependencias de Node.js con npm-check-updates, el modo interactivo, el modo doctor y las mejores prácticas de seguridad de la cadena de suministro." date: 2023-12-06 categories: ["tools"] tags: ["node","npm","javascript"] --- import Button from "@components/widgets/Button.astro"; import Notice from "@components/widgets/Notice.astro"; import ListCheck from "@components/widgets/ListCheck.astro"; import Tabs from "@components/widgets/Tabs.astro"; import Tab from "@components/widgets/Tab.astro"; Node.js tiene un gran ecosistema de paquetes que puedes incorporar a tus proyectos. Estos paquetes son tus **dependencias**, gestionadas por **npm** (Node Package Manager) o herramientas alternativas como pnpm, Yarn y Bun. Las dependencias viven en un archivo llamado **`package.json`** en la raíz de tu proyecto. Este archivo registra el nombre de tu proyecto, la versión, los scripts y cada dependencia que necesita. Aquí tienes una entrada típica: ```json "dependencies": { "express": "^4.17.1" } ``` El número de versión usa prefijos de versionado semántico. El prefijo `^` significa "cualquier versión compatible con 4.x.x" -- así que `^4.17.1` acepta cualquier versión desde 4.17.1 hasta (sin incluir) 5.0.0. El prefijo `~` es más restrictivo, aceptando solo actualizaciones patch dentro de la misma versión minor (p. ej., `~4.17.1` significa 4.17.x). Una versión exacta como `4.17.1` bloquea a esa release concreta. Para instalar dependencias, ejecuta `npm install` en tu terminal. Esto descarga paquetes del registro de npm a una carpeta `node_modules`. Si aún no tienes Node.js instalado, mira cómo [instalar Node.js usando NVM](/es/instalar-nodejs-nvm-macos-ubuntu/) -- es la forma recomendada de gestionar múltiples versiones de Node.js. Los usuarios de Fish shell también pueden ver [cómo usar NVM con Fish Shell](/es/nvm-fish-shell/). Mantener esas dependencias actualizadas es importante. Los paquetes desactualizados acumulan vulnerabilidades de seguridad, se pierden mejoras de rendimiento y con el tiempo se vuelven incompatibles entre sí. Esta guía cubre cómo actualizar las dependencias de Node.js de forma segura en 2026. ## Por qué deberías actualizar las dependencias de Node.js con regularidad Las actualizaciones regulares de dependencias te dan: Solo en 2025, investigadores de seguridad marcaron casi 455.000 paquetes maliciosos en npm. Los ataques a la cadena de suministro son una amenaza real y creciente. Ejecutar dependencias desactualizadas expone tu proyecto a exploits conocidos que ya han sido parcheados upstream. Pero actualizar no está libre de riesgos. Las subidas de versión major (p. ej., Express 4.x a 5.x) pueden incluir breaking changes en la API. Revisa siempre el changelog antes de actualizar a una nueva versión major. Una función en la que confías podría haber sido renombrada, eliminada, o haber cambiado sus parámetros. Usa una estrategia de actualización por etapas (primero patch, luego minor, luego major) para aislar problemas. Con las herramientas y el flujo de trabajo adecuados, puedes actualizar sin romper producción. ## Entendiendo el versionado semántico (semver) Antes de meterte con los comandos de actualización, entiende cómo funcionan los números de versión de npm. Cada paquete sigue la convención **MAJOR.MINOR.PATCH**: | Parte de versión | Qué cambia | Ejemplo | |---|---|---| | **MAJOR** (1ª) | Breaking changes, cambios incompatibles en la API | `4.17.1` → `5.0.0` | | **MINOR** (2ª) | Nuevas funcionalidades, retrocompatible | `4.17.1` → `4.18.0` | | **PATCH** (3ª) | Correcciones de bugs, parches de seguridad, retrocompatible | `4.17.1` → `4.17.2` | `^4.17.1` (caret) -- permite actualizaciones minor y patch dentro de 4.x.x. Este es el comportamiento por defecto de npm. `~4.17.1` (tilde) -- permite solo actualizaciones patch dentro de 4.17.x. `4.17.1` (exacta) -- bloquea a esa versión exacta. Sin actualizaciones automáticas. `>=4.17.1` -- cualquier versión igual o superior a 4.17.1. La mayoría de archivos `package.json` usan prefijos `^`. Esto significa que ejecutar `npm install` traerá la última release patch o minor compatible -- pero nunca una nueva versión major. Para saltar entre versiones major, necesitas una herramienta como npm-check-updates. ## Cómo actualizar todas las dependencias de Node.js con npm-check-updates [npm-check-updates](https://www.npmjs.com/package/npm-check-updates) (ncu) es la herramienta de referencia para subir dependencias a sus últimas versiones. Reescribe los números de versión en tu `package.json` sin instalar nada. Ejecutas `npm install` después. A fecha de 2026, ncu está en v22+ y requiere Node.js `^20.19.0 || ^22.12.0 || >=24.0.0` con npm `>=10.0.0`. ### 1. Instalar npm-check-updates Tienes dos opciones: instalación global o npx. ```sh npx npm-check-updates ``` Ejecuta ncu sin instalar nada globalmente. Este es el enfoque recomendado. Siempre usa la última versión y no contamina tus paquetes npm globales. ```sh npm install -g npm-check-updates ``` Instala ncu globalmente para poder ejecutar `ncu` directamente desde cualquier proyecto. Tendrás que ejecutar `npm update -g npm-check-updates` periódicamente para mantenerlo al día. Usa el nombre completo `npx npm-check-updates`. La forma corta `npx ncu` resuelve a un paquete completamente distinto (sin relación) en npm. Es un error común que lleva a errores confusos. ### 2. Comprobar qué paquetes están desactualizados Ejecuta `ncu` en el directorio de tu proyecto para ver qué paquetes tienen versiones más nuevas disponibles: ```sh ncu ``` La salida se ve así: ``` express ^4.21.0 → ^5.1.0 cors ^2.8.5 → ^3.0.0 dotenv ^16.4.5 → ^16.4.7 uuid ^9.0.1 → ^11.1.0 ``` También puedes usar el comando integrado de npm como alternativa: ```sh npm outdated ``` La diferencia: `npm outdated` muestra lo que está disponible dentro de tus rangos semver actuales. `ncu` muestra las últimas versiones absolutas sin importar las restricciones semver -- incluyendo saltos de versión major. ### 3. Actualizar package.json a las últimas versiones Para reescribir `package.json` con los últimos números de versión: ```sh ncu -u ``` Esto actualiza las cadenas de versión en `package.json` pero **no** instala nada todavía. Verás una salida como: ``` Upgrading /home/user/myproject/package.json [====================] 5/5 100% express ^4.21.0 → ^5.1.0 cors ^2.8.5 → ^3.0.0 dotenv ^16.4.5 → ^16.4.7 uuid ^9.0.1 → ^11.1.0 morgan ^1.10.0 → ^1.10.1 Run npm install to install new versions. ``` ### 4. Instalar los paquetes actualizados Ahora instala las nuevas versiones: ```sh npm install ``` Esto descarga los paquetes actualizados a `node_modules`. Ejecuta tus tests después para asegurarte de que nada se rompió. ### Referencia rápida: comandos de npm-check-updates | Comando | Qué hace | |---|---| | `ncu` | Mostrar paquetes desactualizados (solo lectura) | | `ncu -u` | Actualizar `package.json` a las últimas versiones | | `ncu -i` | Modo interactivo -- elige paquetes uno a uno | | `ncu --doctor -u` | Probar actualizaciones iterativamente para encontrar breaking changes | | `ncu --target patch` | Sugerir solo actualizaciones a nivel patch | | `ncu --target minor` | Sugerir solo actualizaciones minor + patch | | `ncu --filter express` | Comprobar solo paquetes específicos | | `ncu --reject react` | Excluir paquetes específicos de las actualizaciones | | `ncu --dep prod` | Comprobar solo dependencias de producción | | `ncu --cooldown 7` | Omitir paquetes publicados hace menos de 7 días | ## Usar el modo interactivo para actualizar selectivamente Cuando no quieres actualizar todo de golpe, usa el modo interactivo: ```sh ncu -i ``` Esto muestra una lista de paquetes desactualizados con casillas de verificación. Usa las flechas para navegar y la barra espaciadora para activar o desactivar paquetes individuales. Pulsa Enter para aplicar tus selecciones. El modo interactivo es útil cuando: - Quieres actualizar primero unos pocos paquetes seguros y encargarte de los arriesgados después - Estás haciendo un triage en un proyecto con muchas dependencias desactualizadas - Quieres omitir paquetes que sabes que tienen breaking changes Añade `--format group` para organizar la lista por actualizaciones major, minor y patch: ```sh ncu -i --format group ``` Así es fácil aprobar rápidamente todas las actualizaciones patch y omitir las major. ## Usar el modo doctor para actualizaciones major seguras Las actualizaciones de versión major son la parte más arriesgada de actualizar dependencias. El modo doctor lo gestiona automáticamente actualizando paquetes de forma iterativa y ejecutando tu suite de tests para encontrar exactamente qué actualización rompe las cosas. ```sh ncu --doctor -u ``` Así es como funciona: 1. Ejecuta tu suite de tests primero para establecer una línea base (los tests deben pasar inicialmente) 2. Actualiza todos los paquetes a sus últimas versiones 3. Ejecuta los tests de nuevo 4. Si los tests fallan, usa un enfoque de búsqueda binaria. Revierte la mitad de las actualizaciones, prueba, y va acotando hasta encontrar el paquete específico que causa el fallo. 5. Mantiene todas las actualizaciones que pasan y revierte solo la que rompe 6. Repite hasta que todos los paquetes estén probados El modo doctor es la forma más segura de manejar grandes saltos de versión. En lugar de adivinar qué paquete rompió tu app, la herramienta lo localiza por ti. La contrapartida: necesitas una suite de tests funcional, y requiere el flag `-u` para aplicar los cambios de verdad. Disponible desde ncu v8, el modo doctor se ha convertido en una parte estándar de los flujos de trabajo de actualización de dependencias. Funciona con cualquier test runner que salga con un código distinto de cero en caso de fallo. ## Apuntar a niveles de actualización específicos con ncu A veces no quieres lo último de todo. El flag `--target` de ncu te permite controlar lo agresivas que son las actualizaciones: ```sh # Solo actualizaciones patch (correcciones de bugs, parches de seguridad) ncu --target patch # Minor + patch (nuevas funcionalidades, sin breaking changes) ncu --target minor # Permanecer dentro del rango semver actual (lo mismo que haría npm install) ncu --target semver # Versiones pre-release etiquetadas @next ncu --target @next # El número de versión más alto sin importar el dist-tag ncu --target greatest ``` Un enfoque por etapas funciona bien en la práctica: 1. `ncu --target patch -u && npm install && npm test` -- seguro, aplica de inmediato 2. `ncu --target minor -u && npm install && npm test` -- normalmente seguro, prueba después 3. Maneja las actualizaciones major individualmente con el modo doctor También puedes filtrar qué paquetes actualizar: ```sh # Solo actualizar paquetes específicos ncu --filter express,cors # Actualizar todo excepto paquetes específicos ncu --reject react,react-dom # Usar comodines ncu --filter "@types/*" # Solo dependencias de producción (omite devDependencies) ncu --dep prod ``` ## Actualizar dependencias con pnpm, Yarn y Bun npm-check-updates funciona con cualquier gestor de paquetes (solo modifica `package.json`). Pero cada gestor de paquetes también tiene sus propios comandos de actualización integrados: ```sh # Comprobar desactualizados (dentro del rango semver) npm outdated # Actualizar dentro de rangos semver npm update # Actualizar package.json a latest + instalar npx npm-check-updates -u npm install ``` ```sh # Comprobar desactualizados pnpm outdated # Actualizar dentro de rangos semver pnpm update # Actualizar a las últimas versiones (ignorando rangos semver) pnpm update --latest # Modo de actualización interactivo pnpm update --interactive --latest ``` ```sh # Comprobar desactualizados (Yarn 1.x / Classic) yarn outdated # Actualizar dentro de rangos semver yarn upgrade # Actualización interactiva (Yarn Berry / 2+) yarn up -i # Actualizar a latest (Yarn Berry) yarn up --interactive ``` ```sh # Actualizar dependencias dentro de rangos semver bun update # Actualizar a las últimas versiones bun update --latest # Comprobar paquetes desactualizados bun outdated ``` Para profundizar más, mira [cómo actualizar paquetes en Bun](/es/actualizar-paquetes-bun/). También puedes leer nuestra comparativa de [Bun vs npm, Yarn, pnpm y otros](/es/gestor-paquetes-bun/) para elegir el gestor de paquetes adecuado para tu proyecto. Todas estas herramientas respetan los rangos de versión de `package.json` por defecto. Para saltar entre versiones major, normalmente necesitas el flag `--latest` (pnpm, Bun) o una herramienta como ncu. ## Seguridad de la cadena de suministro: cooldowns de dependencias y antigüedad de versiones Esta sección no existía cuando se escribió este artículo por primera vez. Desde entonces, la seguridad de la cadena de suministro se ha convertido en una parte central de la gestión de dependencias. Los ataques a la cadena de suministro en npm se han disparado. En 2025, investigadores de seguridad identificaron casi 455.000 paquetes maliciosos en el registro de npm. Los atacantes secuestran nombres de paquetes populares, inyectan malware en actualizaciones legítimas, o hacen typosquatting de nombres de paquetes comunes. El compromiso de Axios en marzo de 2026 demostró que incluso los paquetes de confianza ampliamente usados no son inmunes. La defensa: **cooldowns de dependencias**, es decir, rechazar instalar paquetes que se publicaron hace muy poco. ### Configurar una antigüedad mínima de versión en .npmrc A partir de **npm 11.10.0** (febrero de 2026), puedes configurar `min-release-age` en tu archivo `.npmrc`: ``` min-release-age=7d ``` Esto le dice a npm que rechace cualquier paquete publicado hace menos de 7 días. La lógica es simple: si una actualización de paquete contiene malware, lo más probable es que la comunidad lo detecte y lo elimine en pocos días. Esperar una semana da tiempo a los investigadores de seguridad a marcar releases maliciosas. ### Usar cooldown con npm-check-updates ncu v20+ detecta automáticamente la configuración de cooldown de la configuración de tu gestor de paquetes: - npm: lee `min-release-age` de `.npmrc` - pnpm: lee `minimumReleaseAge` de `.npmrc` - Yarn Berry: lee `npmMinimalAgeGate` de `.yarnrc.yml` También puedes configurarlo directamente con ncu: ```sh ncu --cooldown 7 ``` Esto omite cualquier paquete publicado hace menos de 7 días al comprobar actualizaciones. Grandes cambios de seguridad están aterrizando en npm v12. Por defecto, los scripts de instalación de las dependencias **no se ejecutarán** sin aprobación explícita. Otros valores por defecto son `--allow-git: none` y `--allow-remote: none`. Para prepararte: - Ejecuta `npm approve-scripts` para autorizar los paquetes de confianza ahora - Ejecuta `npm deny-scripts` para bloquear explícitamente los sospechosos - Prueba tus pipelines de CI/CD con estas restricciones antes de que v12 aterrice Estos cambios detienen un vector de ataque común en el que paquetes maliciosos ejecutan código arbitrario durante `npm install`. Incluso antes de npm v12, puedes dar estos pasos hoy: 1. Añade `min-release-age=7d` a tu `.npmrc` 2. Usa `ncu --cooldown 7` al comprobar actualizaciones 3. Ejecuta `npm audit` regularmente para detectar vulnerabilidades conocidas 4. Configura actualizaciones automáticas de dependencias con Dependabot o Renovate (cubierto abajo) Si estás desplegando apps de Node.js con Docker, mira nuestra guía de [los principales comandos de Docker que necesitas conocer](/es/comandos-docker/) para mejores prácticas de seguridad en contenedores. ## Ejecutar auditorías de seguridad con npm audit Después de actualizar dependencias, ejecuta siempre una auditoría de seguridad: ```sh npm audit ``` Esto comprueba tus paquetes instalados contra la base de datos de avisos de seguridad de npm e informa de vulnerabilidades conocidas. La salida incluye el nivel de severidad (baja, moderada, alta, crítica), el paquete afectado, y la ruta a través de tu árbol de dependencias. Para corregir vulnerabilidades automáticamente: ```sh # Corregir dentro de rangos semver (seguro) npm audit fix # Corregir con subidas de versión major (puede romper cosas) npm audit fix --force ``` npm audit tiene un problema de relación señal-ruido. A menudo marca vulnerabilidades en dependencias transitivas (paquetes de los que dependen tus paquetes) que en realidad no afectan a tu runtime. Un hallazgo de auditoría de "severidad alta" en un paquete solo de desarrollo que corre únicamente durante los tests es distinto de uno en tu ruta de dependencias de producción. Usa `npm audit --omit=dev` para centrarte en las dependencias de producción. No entres en pánico por cada hallazgo de auditoría. Evalúa si la ruta de código vulnerable se usa realmente en tu proyecto. ## Automatizar las actualizaciones de dependencias con Dependabot y Renovate Las actualizaciones manuales funcionan para proyectos pequeños. Para cualquier cosa con CI/CD, automatízalo. ### Dependabot El bot de actualización de dependencias integrado de GitHub. Configúralo en `.github/dependabot.yml`: ```yaml version: 2 updates: - package-ecosystem: "npm" directory: "/" schedule: interval: "weekly" open-pull-requests-limit: 10 reviewers: - "your-github-username" ``` Dependabot crea pull requests automáticamente cuando hay nuevas versiones disponibles. Es gratis para todos los repositorios de GitHub y requiere cero infraestructura. ### Renovate Open source, autoalojable, y mucho más configurable. Ventajas sobre Dependabot: - **Agrupación**: Combina múltiples actualizaciones relacionadas en una sola PR (p. ej., todos los paquetes `@types/*`) - **Automerge**: Auto-fusiona actualizaciones patch que pasan CI - **Horarios**: Ejecuta actualizaciones solo en horario laboral - **Reglas personalizadas**: Coincidencia de paquetes por patrón, tipo de versión, o fuente Se configura vía `renovate.json` en la raíz de tu repo: ```json { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": ["config:base"], "packageRules": [ { "matchUpdateTypes": ["patch"], "automerge": true }, { "matchPackagePatterns": ["@types/*"], "groupName": "type definitions" } ] } ``` Usa Dependabot si estás en GitHub y quieres algo que funcione con cero configuración. Usa Renovate si necesitas agrupación, automerge, o un control más fino sobre el comportamiento de las actualizaciones. ## Buenas prácticas para actualizar dependencias de Node.js de forma segura ### Usa una estrategia de actualización por etapas No actualices todo de golpe. Trabaja por etapas: 1. Crea una rama: `git checkout -b deps-update` 2. Actualiza primero las versiones patch: `ncu --target patch -u && npm install && npm test` 3. Actualiza las versiones minor: `ncu --target minor -u && npm install && npm test` 4. Maneja las versiones major individualmente: `ncu --doctor -u` 5. Commitea y fusiona Esto aísla los problemas. Si algo se rompe, sabes que está en la etapa más reciente. ### Crear un archivo de configuración .ncurc Guarda la configuración de ncu específica del proyecto en `.ncurc.json`: ```json { "reject": ["mongoose", "sequelize"], "target": "minor", "upgrade": true } ``` Esto mantiene ciertos paquetes fijados (quizá sabes que tienen breaking changes) y establece un nivel de actualización por defecto. Ejecuta `ncu` sin flags y leerá esta configuración automáticamente. ### Gestionar conflictos de peer dependencies Cuando los paquetes requieren versiones específicas de dependencias compartidas, surgen conflictos: ```sh # Comprobar problemas de peer dependencies ncu --peer ``` Si te encuentras errores de peer dependencies después de actualizar, prueba: ```sh npm install --legacy-peer-deps ``` Esto le dice a npm que use la resolución de dependencias antigua, más permisiva. Es un workaround, no una solución, pero te desbloquea mientras resuelves el conflicto. Para una solución más permanente, usa el campo `overrides` en `package.json` para forzar versiones específicas: ```json { "overrides": { "some-transitive-dependency": "^2.0.0" } } ``` ### Consejos generales de flujo de trabajo Asegúrate de que tu flujo de trabajo git sea sólido. [Vincular GitHub con SSH](/es/vincular-github-ssh-macos-linux/) hace que pushear ramas y revisar PRs no tenga fricción. ## Conclusión Actualizar dependencias de Node.js no tiene por qué dar miedo. El flujo de trabajo es directo: 1. **Comprueba** qué está desactualizado con `ncu` 2. **Actualiza** por etapas (patch → minor → major) 3. **Prueba** después de cada etapa 4. **Commitea** y fusiona Lo que ha cambiado desde que se publicó este artículo por primera vez es el entorno de seguridad. Los ataques a la cadena de suministro son reales y van en aumento. Configurar cooldowns de dependencias, ejecutar `npm audit`, y montar actualizaciones automatizadas con Dependabot o Renovate ya no son buenas prácticas opcionales. Son higiene básica. Empieza añadiendo `min-release-age=7d` a tu `.npmrc` hoy. Configura una programación semanal de Dependabot. Usa el modo doctor cuando necesites abordar saltos de versión major.