Tengo problemas para entender el 'nuevo' comportamiento de npm en algunos puntos:
npm >= 7 es más estricto con respecto a las dependencias entre pares. Ya publiqué una pregunta para esto aquí . Pero todavía no entiendo completamente el beneficio del comportamiento 'nuevo'. Espero obtener una explicación más práctica. Ahora, cada uno de mis repositorios arroja este error npm install y, según tengo entendido, no puedo hacer nada al respecto, ya que el mantenedor debería haber actualizado los paquetes. Pero en la vida real nunca habrá un punto en el que todos los paquetes estén actualizados.
Recibo varios informes de vulnerabilidades, pero npm audit fix en su mayoría no corrige ninguna vulnerabilidad. Aquí el mismo problema: solo puede ser manejado por el mantenedor, por lo que no puedo hacer nada. Entonces, ¿cómo debo manejar esos informes en la práctica?
Algo similar con los mensajes de desaprobación. Como ejemplo sockjs-node que usa uuid 3.4.0; el último es 8.3.2. Pero el mantenedor no actualiza el paquete, ya que, en su opinión , no es necesario. Así que aquí lo mismo: El mantenedor es el único que puede resolver el problema.
En todos estos casos me gustaría saber cómo manejar esas cosas. ¿Qué estás haciendo? En mi canalización de CI, recibo muchos mensajes de desaprobación y debo usar --legacy-peer-deps lo que prácticamente significa que tengo que usar npm 6 y también recibo muchas vulnerabilidades informadas.
Entonces, nunca será posible obtener una instalación "limpia", ¿verdad?
¿Cuál es el valor de los informes/mensajes, si siempre están ahí, por lo que se vuelven "normales" y tengo que ignorarlos?
Estoy ejecutando npm 7.8.0 y también he tenido este problema en el pasado.
El propósito de esas advertencias es pedirle que se asegure de que las dependencias de sus compañeros sean compatibles. Básicamente es solo un recordatorio de que algo podría salir mal si usa dependencias incompatibles y que debería considerar resolver el desajuste de inmediato.
Desafortunadamente, no sé si hay una manera de ocultar esas advertencias.
Para obtener más información al respecto, consulte este artículo (consulte la sección 'Dependencias de pares') que lo explica muy bien.
Como solución alternativa, descubrí que usar npm i --force o npm i --legacy-peer-deps funciona bien.
De acuerdo con el anuncio de npm para v7:
La instalación automática de dependencias de pares es una característica nueva e interesante que se introdujo en npm 7. En versiones anteriores de npm (4-6), los conflictos de dependencias de pares presentaban una advertencia de que las versiones no eran compatibles, pero aún así instalarían dependencias sin error. npm 7 bloqueará las instalaciones si existe un conflicto de dependencia ascendente que no se puede resolver automáticamente.
El beneficio del nuevo comportamiento de npm es que debe elegir intencionalmente forzar la instalación si hay versiones de dependencia del mismo nivel que no coinciden, lo que se trata de llamar la atención del desarrollador sobre posibles problemas de dependencia en lugar de simplemente imprimir mensajes de advertencia en los registros, que son propensos a obtener ignorado
En general, no debería ser el caso de que siempre tenga errores con las dependencias de pares. Puede darse el caso (como sucede con las aplicaciones Angular, por ejemplo) de que las dependencias de pares no coincidan al actualizar una versión principal (las bibliotecas principales deben actualizarse y luego los complementos, etc.). Pero si siempre obtiene errores de dependencia del par, esto sugiere que una de las dependencias es inapropiadamente estricta en la versión que necesita, o la dependencia está desactualizada, o la dependencia aún no se ha actualizado para que coincida con la versión de su par. .
Sus opciones en estas circunstancias deberían ser (1) degradar las dependencias de pares enumeradas hasta que se actualicen las dependencias que las usan, (2) actualizar las dependencias para mantenerse al día con las versiones enumeradas como pares, (3) forzar la instalación usando npm i --force o npm i --legacy-peer-deps , o (4) abrir un problema o crear un PR para proyectos de código abierto cuyas dependencias de pares son demasiado estrictas o que necesitan actualizarse para mantenerse al día con la última versión de su par.
Con respecto al uso de npm audit , la forma en que maneja los informes depende de sus necesidades. Si, por ejemplo, desea asegurarse automáticamente de que no se incluyan vulnerabilidades críticas en su aplicación, existen varios indicadores (documentados aquí). Por ejemplo, podría usar npm audit --audit-level=moderate para solo mostrar vulnerabilidades que son riesgos moderados o altos. También puede ejecutar npm audit fix --force para forzar la reparación de vulnerabilidades con el riesgo de usar dependencias incompatibles.
En general, usted depende de los mantenedores para eliminar esos molestos mensajes de error (a menos que esté dispuesto a arriesgarse a que muchas cosas se rompan, --force su camino). Entonces, a veces, lo correcto es simplemente ignorar los mensajes de error y seguir adelante. O, si necesita tener más confianza en su postura de seguridad, programe algún tiempo cada pocos meses para revisar esas vulnerabilidades (o desuso) hasta que esté satisfecho.
Y, por supuesto, siempre está la opción que más trabajo da, pero siempre es posible: contribuir al código abierto. Si las dependencias necesitan actualizarse, ofrézcase para hacer las relaciones públicas y las pruebas. Si el mantenedor se niega a actualizar una biblioteca en desuso, siempre existe la opción de bifurcarla y actualizarla usted mismo. Probablemente haya muchas personas que comenzarían a usar una biblioteca bifurcada si demuestra un compromiso para mantener limpia su cadena de dependencia.