ForHosting KIT · Utilidades de desarrollo

Diff de dependencias package.json

Compare dos listas de dependencias de package.json y vea lo que de verdad cambió: react pasa de ^17.0.2 a ^18.2.0, entra axios, sale moment y lodash sigue igual. El formato y el orden de las claves no cuentan. Gratis en su navegador.

  • Gratis
  • Funciona en su navegador
  • Sin registro
  • Sus datos no salen de su equipo
Úselo desde WebAPIEmailTelegramApp pronto

Corre en su navegador. Gratis y sin límite: sus datos no salen de esta página.

Comparar bloques de dependencias entre dos capturas de package.json es una tarea habitual en revisiones de release, actualizaciones y auditorías de pull request. Un diff de texto o de líneas mezcla ruido de formato, orden de claves y campos ajenos con la señal que importa: qué paquetes aparecieron, cuáles salieron y qué rangos de versión se movieron. Este comparador de dependencias de package.json acepta dos objetos planos —cada uno un mapa de nombre de paquete a cadena de rango de versión, tal como en dependencies, devDependencies, peerDependencies u optionalDependencies— y devuelve listas estructuradas de paquetes añadidos, eliminados y modificados, más entradas sin cambio y contadores.

Qué informa un diff semántico de dependencias

Un diff semántico de dependencias trata cada nombre de paquete como elemento de un conjunto y cada campo de versión como etiqueta de cadena unida a ese nombre. Cualquier nombre presente solo en after se informa en added con su nuevo rango de versión. Cualquier nombre presente solo en before se informa en removed con la versión que tenía.

Los nombres en ambos mapas con cadenas de versión distintas aparecen en changed con campos from y to. Los nombres con cadenas idénticas aparecen en unchanged para que pueda inventariar la parte estable del árbol declarado. Los contadores de cada grupo y los totales de ambos mapas permiten a los paneles mostrar insignias sin recontar arrays.

La comparación es deliberadamente superficial: no expande rangos con caret, no resuelve el registro npm ni evalúa si ^17.0.0 y 17.0.2 instalarían el mismo árbol. Así la herramienta permanece determinista, sin red y apta para puertas de CI que solo necesitan saber si el objeto de dependencias declarado se movió.

Dónde aporta valor un diff de dependencias de package.json

Los responsables de release fijan un objeto de dependencias conocido como bueno antes de una oleada de actualizaciones y vuelven a comparar tras lotes de Dependabot o Renovate para confirmar el conjunto previsto de subidas. Los pipelines de revisión de seguridad combinan esta salida estructurada con consultas de avisos: solo la unión de nombres añadidos y cambiados necesita escaneo CVE cuando el resto del árbol no cambió.

Mantenga mapas modestos, fije los arrays ordenados en las pruebas y obtendrá informes reproducibles de cambios de dependencias para CI, revisión de código y listas de migración sin montar un analizador completo de lockfile.

Resúmenes de dependencias en pull requests

Compare los objetos de dependencias de package.json de base y head y publique en el PR solo los paquetes añadidos, eliminados o con versión cambiada.

Revisión de lotes de upgrade y Renovate

Compare el mapa de dependencias antes y después de un lote de actualización automática para verificar las subidas previstas y detectar eliminaciones inesperadas.

Listas de reescaneo de seguridad enfocadas

Alimente a los escáneres de avisos con los nombres de paquetes añadidos y cambiados para no volver a comprobar en cada commit los que no cambiaron.

¿Resuelve rangos semver contra el registro?

No. Las especificaciones de versión se comparan como cadenas exactas. ^1.0.0 y 1.0.0 se tratan como un cambio aunque ambos pudieran instalar el mismo release.

¿Puedo enviar devDependencies o peerDependencies?

Sí. Cualquier mapa nombre→versión sirve: dependencies, devDependencies, peerDependencies, optionalDependencies o un objeto fusionado que construya usted mismo.

¿Por qué no comparar los archivos línea a línea?

Un diff de líneas mezcla el ruido del formato, el orden de las claves y otros apartados con lo que importa. Aquí se compara cada nombre de paquete con su texto de versión, así que solo ve los paquetes que entraron, salieron o cambiaron de versión.

¿Aparecen también los paquetes sin cambios?

Sí. Los paquetes con el mismo texto de versión van en su propia lista, para que pueda inventariar la parte estable. Todas las listas salen ordenadas alfabéticamente y con su recuento.

¿Cómo ayuda en una revisión de seguridad?

Cuando casi todo el árbol sigue igual, solo los paquetes añadidos y los que cambiaron de versión necesitan una nueva consulta de avisos. Pase esos nombres a su escáner en lugar de revisar cada paquete en cada commit.

Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.

POSThttps://api.kit.forhosting.com/dev/semantic-diff-package-json

¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.

curl -X POST https://api.kit.forhosting.com/dev/semantic-diff-package-json \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"before":{"react":"^17.0.2","lodash":"^4.17.21","moment":"^2.29.4"},"after":{"react":"^18.2.0","lodash":"^4.17.21","axios":"^1.6.0"}}'
{
  "before": {
    "react": "^17.0.2",
    "lodash": "^4.17.21",
    "moment": "^2.29.4"
  },
  "after": {
    "react": "^18.2.0",
    "lodash": "^4.17.21",
    "axios": "^1.6.0"
  }
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.semantic_diff_package_json",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.

Por solicitud$0.002

Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.

HTTPCódigoSignificado
401unauthorizedAPI key ausente o inválida.
402insufficient_balanceEl saldo no cubre el precio de la tarea.
404unknown_typeEl tipo de tarea no existe.
429rate_limitedDemasiadas peticiones. Use el webhook en vez de sondear.

Las entradas que no son objetos fallan con invalid_input y no se facturan.

Qué informa un diff semántico de dependencias

El mapa base es before; el mapa candidato es after. Pegue dependencies, devDependencies o una vista fusionada que haya construido usted mismo: el endpoint solo necesita dos objetos con especificaciones de versión en cadena.

Contrato de entrada, forma de respuesta y errores

Cada uno debe ser un objeto plano, no un array, no null y no un primitivo. Los nombres de paquete son claves del objeto; los rangos de versión deben ser cadenas o escalares simples que se conviertan limpios en cadena —se rechazan objetos anidados como valor de versión. Los objetos vacíos son válidos y significan un conjunto vacío de dependencias. En éxito el cuerpo incluye arrays added, removed, changed y unchanged ordenados alfabéticamente por nombre de paquete; cada ítem añadido o eliminado tiene name y version, cada modificado tiene name, from y to, y cada sin cambio tiene name y version. Envíe un cuerpo JSON con dos campos objeto obligatorios: before (alias left, old, previous) y after (alias right, new, next). Los contadores numéricos added_count, removed_count, changed_count, unchanged_count, total_before y total_after reflejan los arrays. El booleano has_changes es true cuando algún paquete se añadió, eliminó o cambió de versión. Si before o after falta, es un array, una cadena u otra cosa que no sea objeto, la tarea falla con invalid_input nombrando el campo; esos fallos no consumen saldo. Ejemplo: before con react ^17.0.2, lodash ^4.17.21, moment ^2.29.4 frente a after con react ^18.2.0, lodash ^4.17.21, axios ^1.6.0 produce moment eliminado, axios añadido, react cambiado de ^17.0.2 a ^18.2.0, y lodash sin cambios.

Dónde aporta valor un diff de dependencias de package.json

Los bots de pull request pueden extraer dependencias de los package.json de base y head, llamar a este endpoint y publicar un comentario breve que liste solo movimientos reales de paquetes en lugar de un diff unificado ruidoso. Como la implementación es parse puro de nivel A, cada llamada exitosa cuesta el precio base publicado $0.002 sin tokens de modelo ni red saliente.

¿Cómo se comparan dos objetos de dependencias de package.json?

Envíe before y after como objetos planos que asocian nombres de paquete a cadenas de rango de versión. La API devuelve listas ordenadas added, removed, changed y unchanged más contadores.

¿Qué ocurre si before o after no es un objeto?

La tarea falla con invalid_input. Se rechazan arrays, null, cadenas y campos ausentes, y no se facturan.

¿Cuánto cuesta el diff de dependencias de package.json?

La herramienta del navegador es gratuita. Las peticiones API usan saldo prepago KIT a $0.002 por llamada exitosa; la entrada inválida no se factura.

Ver la documentación completa del KIT →