Cada lockfile se reconstruye como un grafo de dependencias. En npm, la ruta node_modules de cada entrada codifica dónde se instaló, y una dependencia se resuelve igual que lo hace Node: primero en tu propio node_modules y luego subiendo hacia la raíz. En pnpm el grafo ya es plano: cada instancia instalada se identifica por nombre y versión, y sus dependencias apuntan a otras claves. Después los dos grafos se comparan por nombre de paquete, cada salto de versión se clasifica como major, minor, patch o prerelease, y para cada cambio la herramienta hace una búsqueda en anchura desde la raíz para hallar las cadenas más cortas que llevan a ese paquete. El primer salto de esa cadena cuya versión difiere entre los dos lockfiles es el que trajo el cambio.
salto major marca una actualización cuyo primer número de versión cambió: el único nivel donde por convención se permiten cambios incompatibles, así que merece una mirada aunque sea transitivo. transitivo nuevo marca un paquete que apareció sin que nadie lo declarara en package.json; llegó a través de otra dependencia. N versiones instaladas significa que el resolutor no pudo satisfacer todos los rangos con una sola copia, así que el mismo paquete se instaló más de una vez; normalmente inofensivo, a veces causa de estado duplicado o sorpresas con instanceof. origen cambiado significa que el tarball ahora proviene de otro host de registro, algo que conviene verificar antes de fusionar.
Los lockfiles suelen contener URLs de registros privados y nombres de paquetes internos. El análisis, la comparación y el rastreo de cadenas se ejecutan en tu navegador: nada se sube, se guarda ni se envía a analítica. Puedes comprobarlo abriendo la pestaña de red mientras pegas.
Preguntas y respuestas frecuentes sobre este tema.
Pega el lockfile antiguo a la izquierda y el nuevo a la derecha. En un pull request, abre el archivo en la rama base y en la rama head (o ejecuta git show main:package-lock.json y git show HEAD:package-lock.json). Tras una instalación local que cambió el lockfile, git show HEAD:package-lock.json te da la versión anterior y la copia de trabajo es la nueva. Ambos lados deben ser el mismo tipo de lockfile: npm con npm, pnpm con pnpm.
Una dependencia directa es la que declara tu package.json. Una transitiva es todo lo demás en el lockfile: está ahí porque una dependencia directa, o una de sus dependencias, la necesita. La mayor parte de un lockfile es transitiva, por eso un cambio de una línea en package.json puede producir cientos de líneas cambiadas. La etiqueta directa en la tabla marca los paquetes que declaraste tú; todo lo que no la tiene llegó por una cadena, y la vista de cadena muestra cuál.
npm package-lock.json con lockfileVersion 1, 2 y 3, y pnpm-lock.yaml con lockfileVersion 5, 6 y 9. npm-shrinkwrap.json usa el mismo formato que package-lock.json y también funciona. yarn.lock (tanto el formato de texto clásico v1 como el YAML de Berry) se detecta pero aún no es compatible, y la herramienta lo indica en lugar de adivinar. Ten en cuenta que npm lockfileVersion 1 no tiene lista de dependencias raíz, así que en esos archivos la etiqueta directa se infiere de la posición de nivel superior en vez de leerse de package.json.
git diff muestra líneas, no paquetes: una actualización toca sus líneas version, resolved e integrity más cada entrada que la referenciaba, así que el mismo cambio queda disperso por el archivo. La vista de dependencias de GitHub lista paquetes añadidos, eliminados y cambiados, pero solo en GitHub y solo como lista plana: no te dice que minimatch saltó un major porque rimraf se actualizó. Esta herramienta trabaja con cualquier par de lockfiles que puedas pegar, agrupa los cambios por paquete, clasifica el salto y muestra la cadena que lo explica.
Para cada paquete cambiado busca en el lockfile nuevo (o en el antiguo, para eliminaciones) desde la raíz hacia fuera y conserva las cadenas más cortas que llegan al paquete. Luego recorre la cadena más corta desde la raíz y se detiene en el primer salto cuya versión es distinta en el otro lockfile; ese salto se reporta como la causa, por ejemplo 'provocado por rimraf al pasar de 3.0.2 a 6.0.1'. Si el paquete está declarado directamente, la causa es el propio package.json. Si ningún salto cambió, lo más probable es que el paquete se moviera porque el resolutor re-resolvió o deduplicó el árbol, y la herramienta lo dice en lugar de inventar una causa.
No por sí mismo. Cuando dos dependencias exigen rangos que ninguna versión única satisface, el gestor de paquetes instala ambas y anida una de ellas; el lockfile registra cada copia por separado y esta herramienta las lista como N versiones instaladas. Es normal y suele ser inofensivo. Vale la pena corregirlo cuando el paquete mantiene estado compartido o exporta clases comprobadas con instanceof, o cuando el duplicado es lo bastante grande como para afectar al tamaño del bundle. Consulta las cadenas para ver qué dependencia insiste en el rango antiguo.