Node: La suma de verificación de integridad falló al usar sha1 - Node v8+

Entonces, el problema aquí es esta advertencia, ¿verdad?

npm WARN registry Unexpected warning for https://registry.npmjs.org/: Miscellaneous Warning EINTEGRITY: sha1-UWbihkV/AzBgZL5Ul+jbsMPTIIM= integrity checksum failed when using sha1: wanted sha1-UWbihkV/AzBgZL5Ul+jbsMPTIIM= but got sha512-yJHVQEhyqPLUTgt9B83PXu6W3rx4MvvHvSUvToogpwoGDOUQ+yDrR0HRot+yOCdCO7u4hX3pWft6kWBBcqh0UA==. (11423 bytes)

Eso parece un problema de npm, debe plantear esto en su rastreador ( npm/npm ).

Una mirada superficial a su rastreador sugiere que se trata de un duplicado de https://github.com/npm/npm/issues/17146.

Cierro esto, comenta si he entendido algo mal y vuelvo a abrir.

gracias @gibfahn lo publicaré allí.

Comentario troll eliminado. La próxima vez que sea una prohibición permanente, @chaudharisuresh997.

10621 verbose Windows_NT 10.0.15063
10622 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install" "--save"
10623 verbose node v8.2.1
10624 verbose npm  v5.3.0
10625 error code EINTEGRITY
10626 error sha1-PTDHGLCaPZbyPqTMH0A8TTup/08= integrity checksum failed when using sha1: wanted sha1-PTDHGLCaPZbyPqTMH0A8TTup/08= but got sha1-IddJ0tf3FO+KgwifNonymtHE/tw=. (15860 bytes)
10627 verbose exit [ 1, true ]

Obteniendo un error al instalar el paquete npm

12256 tipo detallado OperationalError
12257 Error de pila detallada: sha1-b3oaQGRG+i4YfslTmGmPTO5HYmk= la suma de comprobación de integridad falló al usar sha1: quería sha1-b3oaQGRG+i4YfslTmGmPTO5HYmk= pero obtuvo sha1-juRg3eV2OcAghs1D6DFD5ZC4ezU=. (130548 bytes)
12257 pila detallada en Transform.on (E:\nodejs\node_modules\npm\node_modules\ssri\index.js:275:19)
12257 pila detallada en emitNone (events.js:110:20)
12257 pila detallada en Transform.emit (events.js:207:7)
12257 pila detallada en endReadableNT (_stream_readable.js:1059:12)
12257 pila detallada en _combinedTickCallback (internal/process/next_tick.js:138:11)
12257 pila detallada en process._tickCallback (internal/process/next_tick.js:180:9)
12258 verbose cwd E:\j Ejercicio angular\loginEx
12259 detallado Windows_NT 6.1.7601
12260 verbose argv "E:\nodejs\node.exe" "E:\nodejs\node_modules\npm\bin\npm-cli.js" "instalar"
12261 nodo detallado v8.4.0
12262 detallado npm v5.3.0
12263 código de error INTEGRIDAD
12264 error sha1-b3oaQGRG+i4YfslTmGmPTO5HYmk= la suma de verificación de integridad falló al usar sha1: quería sha1-b3oaQGRG+i4YfslTmGmPTO5HYmk= pero obtuvo sha1-juRg3eV2OcAghs1D6DFD5ZC4ezU=. (130548 bytes)
12265 salida detallada [1, verdadero]

Aquí igual
`8944 tipo detallado OperationalError
8945 Error de pila detallada: sha1-wNWmOycYgArY4ESSTpSachN1BhF4= la suma de comprobación de integridad falló al usar sha1: quería sha1-wNWmOycYgArY4ESSTpSachN1BhF4= pero obtuvo sha1-wNWmOycYgArY4esPpSachN1BhF4=. (8058 bytes)
8945 pila detallada en Transform.on (C:\Program Files\nodejs\node_modules\npm\node_modules\ssri\index.js:275:19)
8945 pila detallada en emitNone (events.js:110:20)
8945 pila detallada en Transform.emit (events.js:207:7)
8945 pila detallada en endReadableNT (_stream_readable.js:1059:12)
8945 pila detallada en _combinedTickCallback (internal/process/next_tick.js:138:11)
8945 pila detallada en process._tickCallback (internal/process/next_tick.js:180:9)

8949 nodo detallado v8.4.0
8950 detallado npm v5.3.0`

Hola @Rogasch , te sugiero que desinstales completamente node y npm. También elimine la carpeta npm y npm-cache . Y vuelva a instalar usando el instalador node-v6.11.2-x86.msi .

tuve el mismo problema y
npm instalar -g npm
lo arregló para mí

Tuve este problema cuando incluí package-lock.json en la confirmación. Después de eliminar package-lock.json, pude ejecutar npm install sin errores nuevamente.

@GottfridL, pero ¿cómo funciona este bloqueo de paquete, json? ¿Por qué se ha generado? Porque su solución funcionó para mí, pero cuando el comando terminó, apareció un mensaje que decía que necesito un archivo package-lock.json, aunque la ejecución fue exitosa

El aviso de npm creó un archivo de bloqueo como package-lock.json.

Hemos tenido el mismo problema en nuestras compilaciones de Travis desde que actualizamos a Node 8 e incluimos package-lock.json en nuestras confirmaciones. npm 5.5.1

Hola amigos,

Para mí, la opción "borrar caché" funcionó, ¡pero no usé los comandos npm commands!

(esto será diferente para todos, pero tal vez ayude)
Mi problema resultó ser que los directorios dentro ~/.npm/_cacache/index-v5 eran propiedad de root debido a las instalaciones y desinstalaciones anteriores que probé.
Después de eliminar manualmente esos directorios, la instalación de npm funcionó.

TLDR: Borrar caché. Hágalo manualmente si todavía ocurre.

Mi problema resultó ser que los directorios dentro de ~/.npm/_cacache/index-v5 eran propiedad de root debido a las instalaciones y desinstalaciones anteriores que probé.

¿Funciona sudo npm cache clean -f ?

@gibfahn
No, para mí no fue así porque el problema no era que el caché necesitara ser limpiado, sino que otros procesos estaban tratando de _crear_ archivos en el caché y no podían.

Con respecto al Registro, en mi caso, creo que el problema fue que el archivo JSON con información no se pudo guardar y, por lo tanto, no se pudo realizar la verificación SHA.

Para mí, había una instancia en ejecución de npm en la memoria. Después de matar el proceso, el problema desapareció.

Supongo que package-lock.json debe permanecer comprometido y actualizado. Dado que este archivo garantiza que los mismos paquetes utilizados y probados en la etapa de desarrollo serán los mismos.

En otras palabras: la eliminación de package-lock.json funciona, sin embargo, no es la solución correcta.

Tuve el mismo problema después de actualizar a nodejs 10.x. Tuve que instalar npm npm -g, luego eliminar todos los archivos package-lock.json. Esto nos permite construir más de nuestra aplicación, pero todavía hay algunas incompatibilidades en alguna parte y estamos tratando de resolverlas.

teniendo el mismo problema en mi MacBookPro

Node 10.8.0
npm 6.2.0

, cuando voy a mi proyecto y problema
npm install , me siguen

mycomp:MyProj nbnex$ npm i
WARN tarball tarball data for [email protected] (sha1-6GFJ7dp3tKYSvYAb/EVjK+zOYGQ=) seems to be corrupted. Trying one more time.
WARN tarball tarball data for [email protected] (sha1-6GFJ7dp3tKYSvYAb/EVjK+zOYGQ=) seems to be corrupted. Trying one more time.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/@angular-devkit/core/node_modules/fsevents):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename '/Users/dbnex/source/MyProj/MyProj/node_modules/.staging/fsevents-d35eda14/node_modules/yallist' -> '/Users/dbnex/source/MyProj/MyProj/node_modules/.staging/yallist-2c29e2bb'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/watchpack/node_modules/fsevents):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename '/Users/dbnex/source/MyProj/MyProj/node_modules/.staging/fsevents-6a393e92/node_modules/set-blocking' -> '/Users/dbnex/source/MyProj/MyProj/node_modules/.staging/set-blocking-5346d4b2'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/webpack-dev-server/node_modules/fsevents):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename '/Users/dbnex/source/MyProj/MyProj/node_modules/.staging/fsevents-a915511c/node_modules/process-nextick-args' -> '/Users/dbnex/source/MyProj/MyProj/node_modules/.staging/process-nextick-args-7b3b7565'

npm ERR! code EINTEGRITY
npm ERR! Verification failed while extracting [email protected]:
npm ERR! Verification failed while extracting [email protected]:
npm ERR! sha1-6GFJ7dp3tKYSvYAb/EVjK+zOYGQ= integrity checksum failed when using sha1: wanted sha1-6GFJ7dp3tKYSvYAb/EVjK+zOYGQ= but got sha512-EUet5nra7Ia1J4AkdJR6ToUFZHPbN9uybPpv+wx5/jo8lch5ezvh/5MQSShxIeU2bvsv4YpcSqgEq/6iBBfgpQ== sha1-dRAb4fP7cqda60ct3CvKQ5zMJxY=. (178201 bytes)

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/dbnex/.npm/_logs/2018-10-05T18_04_47_761Z-debug.log

cierre el servidor de nodos y ejecute el comando, funcionó para mí.

Para cualquiera que todavía tenga este problema, el problema está en el archivo package-lock.json . Para las personas que trabajan en equipo, no confirme su archivo package-lock.json para que cualquier persona que recoja su proyecto obtenga un archivo package-lock.json recién generado después de ejecutar npm i Espero que esto ayude a alguien, Saludos

Gracias @bunday , ¡me resolvió el problema!

@bunday Si elimina el archivo package-lock.json, todos actualizarán los paquetes por su cuenta. El objetivo del bloqueo de paquetes es evitar esto.
Resolvimos el problema eliminando manualmente los paquetes en cuestión (que eran dependencias compiladas localmente) del paquete-lock.json y confirmándolos.

La eliminación de package-lock.json es una solución única para este problema, por favor no tome el consejo de:

no confirme su paquete-lock.json

Está destinado a comprometerse a crear cierta apariencia de estabilidad en su árbol de dependencias, es muy útil especialmente con CI e implementando su proyecto en algún lugar que instale los node_modules de forma remota.

Enviar package-lock.json es mejor que enviar node_modules, lo cual es una locura.

¡npm install -g resolvió mi problema!
Realmente puedo apreciar la ayuda si alguien puede decirme por qué ocurre este error y cuál es su causa raíz.

@sudipt1999 en mi caso, el problema fue que instalamos desde el registro A que se guardó en el bloqueo del paquete, luego, un tiempo después, cambiamos al registro B en .npmrc e intentamos instalarlo nuevamente.

Por alguna razón, el SHA1 fue diferente entre estos dos registros.

La solución fue eliminar package-lock y node_modules, y luego volver a generar dependencias y package-lock con npm i.

Tenía el mismo problema. Eliminar package-lock.json y ejecutar npm cache clear -f solucionó el problema.
Esto sucedió cuando instalé un módulo en node 6 y luego lo reinstalé en node 8

Enviar package-lock.json es mejor que enviar node_modules, lo cual es una locura.

@jakewhelan , ¿algún problema con no confirmar package-lock.json y confiar en el buen 'ol package.json? Sé que esto elimina algunas eficiencias obtenidas con package.lock, pero estoy cansado de tratar con desarrolladores que usan diferentes versiones de nodos y/o hilos y me encuentro con problemas en los que package.lock no está sincronizado. La solución parece ser siempre eliminar package.lock. No vale la pena en mi humilde opinión.

No creo que nadie sugiera cometer node_modules;)

Enviar package-lock.json es mejor que enviar node_modules, lo cual es una locura.

@jakewhelan , ¿algún problema con no confirmar package-lock.json y confiar en el buen 'ol package.json? Sé que esto elimina algunas eficiencias obtenidas con package.lock, pero estoy cansado de tratar con desarrolladores que usan diferentes versiones de nodos y/o hilos y me encuentro con problemas en los que package.lock no está sincronizado. La solución parece ser siempre eliminar package.lock. No vale la pena en mi humilde opinión.

No creo que nadie sugiera cometer node_modules;)

El problema es que el buen 'ol package.json solo se preocupa por respetar la especificación de Semver, no le importa una mierda si su aplicación funciona o no. Tampoco le importa hacer un seguimiento de su legado de dependencia.

Si no confirma package-lock.json, corre el riesgo de tener diferentes dependencias cada vez que npm i . Esto significa una diferencia entre los artefactos locales, de CI y de implementación/compilación, y también la diferencia entre lo que cada desarrollador tiene como local. Me resulta difícil llamar a una versión de mi código una 'versión' cuando cambia después de cada instalación, y no me gusta que el código se comporte de manera diferente en producción que en mi entorno local: una gran bandera roja.

Otro problema es que si alguna vez necesita retroceder o volver a una versión anterior para depurar algo, todas sus dependencias serán diferentes de la última vez que estuvo allí; nunca podrá reproducir esa dependencia relacionada. problema de producción sin package-lock.json porque su legado de dependencia se pierde sin package-lock.json.

Son muchas partes móviles con las que personalmente no me siento cómodo.

En mi opinión, solo hay dos opciones sanas que permiten una confianza total en su aplicación:

• Confirmar paquete-lock.json
• No confirme package-lock.json PERO no use ningún operador de Semver ( ^ ~ >= <= ). Debe especificar versiones explícitas. Esta es una pesadilla de mantenimiento, pero tal vez lo considere menos doloroso que sus problemas de bloqueo de paquetes.

Para ser honesto, @wrabbit23 nuestro flujo de trabajo es que cada vez que instalamos la aplicación para el desarrollo local, eliminamos el paquete-lock.json y node_modules de todos modos y luego instalamos de nuevo. Esto resolvería tu problema.

Mientras la aplicación siga funcionando después npm i nuevamente, confirme el nuevo bloqueo del paquete y aún puede estar seguro de que seguirá siendo el mismo a medida que se mueve a través de diferentes entornos.

Eso es lo mejor de ambos mundos.

Eliminamos ^ y ~ de nuestras versiones en todos nuestros archivos package.json. Queremos el control absoluto. A nosotros no nos da ningún problema.

tuve el mismo problema y
npm instalar -g npm
lo arregló para mí

Tuve este problema cuando incluí package-lock.json en la confirmación. Después de eliminar package-lock.json, pude ejecutar npm install sin errores nuevamente.

esto funcionó

Tuve este problema cuando incluí package-lock.json en la confirmación. Después de eliminar package-lock.json, pude ejecutar npm install sin errores nuevamente.

Fue útil. Resolvió este problema usando esta forma.
Ejecuto el proyecto anterior sin ningún cambio con los paquetes npm, pero en un entorno diferente en el registro npm.
Lo ejecuto en Docker. copie el paquete.json y el paquete-lock.json en la ventana acoplable.
ver este error.
arreglado después de eliminar el paquete-lock.json

Ninguno de los anteriores funcionó para mí.

Probé hilo y este es el error exacto que estoy recibiendo ahora