- ¿Por qué debemos actualizar las dependencias?
- ¿Cómo actualizamos con npm?
- Definir las versiones en package.json
- El archivo de bloqueo: package-lock.json
- ¿Cómo garantizar que todos en el equipo usen las mismas versiones?
En esta lección, vamos a aprender a manejar las dependencias de un proyecto usando npm. No te asustes: lo vamos a hacer paso a paso, como si estuviéramos trabajando en un mismo equipo.
Al final, vas a saber cómo actualizar paquetes sin dañar tu aplicación, entender cómo funcionan las versiones en package.json y qué es ese archivo llamado package-lock.json que muchas veces ignoramos.
¿Por qué debemos actualizar las dependencias?
Las bibliotecas que usamos en nuestros proyectos siempre están cambiando. Se actualizan constantemente para:
🐞 Corregir errores (bugs)
⚡ Hacer el código más rápido
✨ Agregar nuevas funcionalidades
Por eso, es importante saber actualizarlas de forma segura.
¿Cómo actualizamos con npm?
Si estamos trabajando con un proyecto que usa npm (el gestor de paquetes de Node.js), hay dos formas comunes de actualizar dependencias:
Actualizar todas las dependencias
npm update
Este comando intenta actualizar todos los paquetes de acuerdo con lo que esté permitido en tu archivo package.json.
Actualizar una dependencia específica
npm update nombre-del-paquete
Este comando actualiza solo el paquete que indiques, si es que hay una versión más reciente compatible con lo que pusiste en package.json.
Definir las versiones en package.json
En el archivo package.json definimos qué versiones de cada dependencia necesitamos. Vamos a ver un ejemplo:
"dependencies": {
"package1": "*",
"package2": "1.3.5",
"package3": "~2.3.4",
"package4": "^2.3.4"
}
| Versión | ¿Qué significa? |
|---|---|
"*" |
Acepta cualquier versión disponible. Puede ser arriesgado. |
"1.3.5" |
Solo admite esa versión exacta. No se actualizará nunca automáticamente. |
"~2.3.4" |
Permite actualizar solo el último número: correcciones menores, como 2.3.5. |
"^2.3.4" |
Permite actualizar dentro de la misma versión mayor: desde 2.3.4 hasta 2.x.x, pero no 3.0.0. |
¿Cuál opción deberíamos usar?
⚠️ "*": Muy riesgoso. Puedes terminar instalando algo que rompa tu código.
🔒 "1.3.5": Súper seguro, pero quedarás con versiones viejas (sin mejoras ni parches).
✅ "~" y "": Son las más recomendadas. Permiten actualizaciones controladas.
El archivo de bloqueo: package-lock.json
Cuando instalamos dependencias con npm, se genera automáticamente un archivo llamado package-lock.json.
Este archivo sirve para:
Guardar las versiones exactas que se instalaron (incluyendo las dependencias internas de otros paquetes, conocidas como dependencias transitivas).
Garantizar que todos en el equipo de desarrollo tengamos las mismas versiones.
Evitar sorpresas al instalar nuevas versiones sin que nos demos cuenta.
¿Qué son las dependencias transitivas?
Ejemplo:
Imagina que instalamos una biblioteca A:
- Nosotros instalamos A.
- Pero A necesita B para funcionar. Entonces, npm instala también B.
Esto puede volverse un problema si B se actualiza y deja de ser compatible con A, o si rompe algo en nuestro código. A esta situación se le conoce como: el infierno de las dependencias transitivas 😈
Por eso es que package-lock.json es tan importante: evita que se instalen versiones inesperadas de esas dependencias.
Ejemplo de package-lock.json
{
"name": "mi-proyecto",
"version": "1.0.0",
"dependencies": {
"express": {
"version": "4.17.1",
"requires": {
"body-parser": "^1.19.0",
"cookie-parser": "~1.4.5"
}
}
}
}
Este archivo guarda exactamente qué versión de cada paquete (y subpaquete) fue instalada. Así, si alguien más clona el proyecto, tendrá la misma configuración.
¿Cómo garantizar que todos en el equipo usen las mismas versiones?
Si varias personas trabajan sobre el mismo proyecto o vas a instalar dependencias en producción, lo ideal es usar:
npm ci
Este comando:
Instala exactamente las versiones que están en package-lock.json.
Borra la carpeta node_modules y reconstruye todo desde cero.
Es más rápido y predecible que
npm install.
Úsalo especialmente en:
Servidores
Entornos de producción
Proyectos colaborativos
Sistemas de integración continua (como GitHub Actions o Docker)
Resumen
- Las dependencias deben actualizarse para recibir mejoras y parches de seguridad.
- Usa
npm updatepara actualizar todas, onpm update nombre-del-paquetepara una sola. - En package.json<, los símbolos
~y^permiten actualizar versiones sin perder compatibilidad. - El archivo package-lock.json fija versiones exactas, incluyendo las dependencias transitivas.
- No edites package-lock.json a mano: npm lo maneja automáticamente.
- Usa
npm cipara asegurar que se instalen siempre las mismas versiones en todos los entornos.
Si entiendes bien cómo funcionan las versiones y el sistema de bloqueo de npm, podrás mantener tus proyectos actualizados sin miedo a que algo se rompa.
Trabajo independiente
📦 Actualiza y controla versiones de paquetes
Vamos a ver cómo actualizar dependencias y cómo fijar versiones exactas para que el comportamiento de tu proyecto sea más predecible.
1️⃣ Clona y actualiza el proyecto de ejemplo:
git clone https://github.com/hexlet-boilerplates/nodejs-package.git cd nodejs-package npm update
💡 Este comando instala las últimas versiones permitidas por las reglas definidas en package.json.
2️⃣ Revisa qué cambió en package-lock.json
Este archivo registra las versiones exactas que se instalaron. Compara su contenido con:
git diff
3️⃣ Fija una versión exacta de un paquete:
- Abre
package.jsonen tu editor. - Busca una dependencia como
"eslint": "^8.0.0". - Cambia esa línea a
"eslint": "8.10.0"(sin el símbolo ^).
🔍 Para saber qué versiones existen, puedes usar:
npm info eslint versions --json
📥 Luego instala esa versión específica:
npm install
4️⃣ Confirma el cambio:
Verifica que la versión instalada sea la que pediste:
git diff
Para acceder completo a curso necesitas un plan básico
El plan básico te dará acceso completo a todos los cursos, ejercicios y lecciones de Códica, proyectos y acceso de por vida a la teoría de las lecciones completadas. La suscripción se puede cancelar en cualquier momento.
