Marc Semper Lloret
← Node.js: JavaScript fuera del navegador

Sesión 5 · Semana 2

Dependencias y versiones

Hoy · Hoja de ruta

  1. 1. Aprende: Cómo se instala una dependencia, qué es el versionado semántico y qué hace el fichero de bloqueo.
  2. 2. Haz: Analiza dependencias reales antes de decidir si las instalarías.
  3. 3. Comprueba: Sabes decir qué versiones acepta cada especificación.

Antes de empezar · 5 minutos, sin apuntes

  1. ¿Qué riesgo tiene meter en tu proyecto código escrito por desconocidos?
  2. Si funciona en tu portátil y no en el del profesor, ¿qué puede haber cambiado?
  3. ¿Por qué crees que no se sube node_modules al repositorio?

Instalar

npm install express            # dependencia de ejecución
npm install --save-dev nodemon # solo para desarrollar
npm install                    # todo lo declarado, en un proyecto clonado
npm uninstall express
npm outdated                   # qué se ha quedado atrás
npm audit                      # vulnerabilidades conocidas

Instalar crea o actualiza tres cosas: la entrada en package.json, el árbol real en node_modules y el package-lock.json.

Versionado semántico

    4 . 21 . 2
    │    │   └── parche · corrección compatible
    │    └────── menor  · funcionalidad nueva, compatible
    └─────────── mayor  · cambio que rompe
Se escribe Acepta
4.21.2 Exactamente esa
~4.21.2 Parches: 4.21.x
^4.21.2 Menores y parches: 4.x.x
* Cualquiera. No lo hagas

El acento circunflejo es el valor por defecto de npm, y es la razón de que dos instalaciones del mismo package.json en días distintos puedan traer código distinto.

El fichero de bloqueo

El package-lock.json se sube al repositorio

Guarda la versión exacta de cada paquete y de cada dependencia de cada paquete. Es lo que hace que tu proyecto instale hoy lo mismo que instaló ayer, y en el portátil del profesor lo mismo que en el tuyo.

Sin él, «en mi máquina funciona» deja de ser una broma. Y node_modules, en cambio, no se sube nunca: son miles de ficheros reconstruibles con un solo comando.

Antes de instalar, pregúntate

Cuatro preguntas antes de añadir una dependencia
  1. ¿Lo resuelve Node de fábrica?
  2. ¿Cuántas dependencias arrastra consigo?
  3. ¿Se mantiene: última publicación, incidencias abiertas?
  4. ¿Sabría hacerlo sin ella si mañana desaparece?

Cada dependencia es código que se ejecuta con tus permisos, que puede tener vulnerabilidades y que alguien tiene que seguir manteniendo. En este proyecto vas a instalar exactamente una.

Tarea 5 · Analizar sin instalar

  1. Crea el .gitignore con node_modules y .env.
  2. Busca la ficha de tres paquetes conocidos y anota versión, dependencias y última publicación.
  3. Di qué versiones acepta cada una de estas especificaciones: ^2.4.1, ~2.4.1, 2.4.1.
  4. Instala Express, mira qué cambió en los tres sitios, y desinstálalo.
  5. Ejecuta npm audit y lee el informe.
  6. Borra node_modules, ejecuta npm install y comprueba que todo vuelve.
Objetivo mínimoAnálisis de tres paquetes y dominio de las especificaciones de versión.
Si lo tienesExplica qué pasaría si un paquete publicara una versión mayor con cambios incompatibles.
RetoBusca un caso real de paquete comprometido y resume qué ocurrió.

Checkpoint · fin de la sesión 5

  • Interpretas una versión semántica y sus rangos.
  • Sabes qué se sube al repositorio y qué no.
  • Evalúas una dependencia antes de instalarla.
  • Reconstruyes node_modules desde cero.

Antes de cerrar · 2 minutos, sin mirar

  1. ¿Qué acepta ^1.2.3?
  2. ¿Para qué sirve el fichero de bloqueo?
  3. ¿Por qué no se sube node_modules?
Ver respuestas

1 · Cualquier 1.x.x igual o posterior: menores y parches, no la versión mayor.

2 · Para que todas las instalaciones traigan exactamente las mismas versiones.

3 · Porque es reconstruible, pesa muchísimo y depende del sistema donde se instale.