Archivos de bloqueo y dependencias transitivas

El manifiesto del proyecto (en Node.js, package.json) declara las dependencias directas y, casi siempre, un rango de versiones aceptables para cada una. El rango con acento circunflejo admite cualquier versión que no cambie el primer número distinto de cero: ^1.2.3 acepta desde la 1.2.3 hasta antes de la 2.0.0, pero ^0.2.3 solo hasta antes de la 0.3.0. La virgulilla es más estrecha: ~1.2.3 se queda dentro de la 1.2. Con rangos, dos instalaciones hechas en días distintos pueden traer versiones distintas.

El archivo de bloqueo (package-lock.json) congela el resultado de una instalación: la versión exacta de cada paquete del árbol, directo o no, de dónde se descargó (resolved) y la suma de integridad del archivo descargado (integrity). En su formato actual, las entradas van bajo packages y la clave de cada una es la ruta en la que queda dentro de node_modules. Si una dependencia necesita una versión incompatible con la que está en la raíz, recibe su propia copia anidada bajo su carpeta.

Para seguridad esto tiene una consecuencia directa: lo que está en producción lo dice el archivo de bloqueo, no el manifiesto. Una alerta se contrasta contra el bloqueo, y un arreglo se comprueba en el bloqueo.

Abre el laboratorio y lee encargo.txt, package.json y alerta-escaner.txt. El paquete de la alerta no figura en el manifiesto: es una dependencia transitiva, la dependencia de una dependencia. Para saber por qué está ahí hay que subir por el árbol hasta llegar a algo que sí declaró el proyecto. La salida de npm ls del archivo arbol-analiza-fechas.txt hace ese recorrido, y el archivo de bloqueo lo confirma en el campo dependencies de cada entrada.

El árbol enseña dos versiones del mismo paquete instaladas a la vez. No es un error: cada dependencia pidió un rango distinto y el gestor no pudo satisfacer los dos con una sola copia, así que dejó una en la raíz y otra anidada. Por eso «ya tenemos la versión nueva» no basta para cerrar una alerta: hay que saber cuál de las copias está afectada y dónde vive.

Hay tres maneras de mover una dependencia transitiva. La primera es que el rango que pide su padre ya admita una versión corregida: entonces basta con actualizar esa entrada del bloqueo, sin tocar el manifiesto, y revisar el cambio. La segunda es actualizar el padre a una versión que pida otra cosa, lo que puede traer cambios incompatibles. La tercera es forzar la versión desde la raíz del proyecto (en npm, el campo overrides), útil cuando el padre no ha publicado nada, pero que obliga a probar que el padre funciona con una versión que no eligió.

Lo que no sirve es añadir el paquete como dependencia directa con la versión buena: el padre sigue pidiendo su rango y conserva su copia anidada. Y borrar el archivo de bloqueo para regenerarlo todo cierra la alerta a costa de cambiar a ciegas cientos de versiones que nadie revisará. Compara el aviso, el rango que pide el padre y las versiones publicadas del padre en registro-calendario-util.txt, y lee las tres propuestas de notas-equipo.txt.

Un archivo de bloqueo solo protege si la instalación lo respeta. Según el gestor y su configuración, la orden de instalación de uso diario puede actualizar el bloqueo cuando el manifiesto y el bloqueo no coinciden, y entonces lo que se construye no es lo que se revisó. Para eso existe una orden de instalación limpia (npm ci), que instala exactamente lo que dice el bloqueo, falla si no concuerda con el manifiesto y nunca lo reescribe. Lee pipeline.txt y la observación del equipo de plataforma.