Hi, had the same problem here. It seems it's affecting only npm version 5.x.x. Downgraded to npm@4.6.1 and all packages were installed correctly.

Update 14.06 (3/3): after deleting NPM cache (with npm cache clear --force) and <project>/node_modules from all target systems (RHEL6, OSX, Windows 8), reinstalling the project modules with npm install --no-shrinkwrap --update-binary and shrinkwrapping afterwards (with npm shrinkwrap), I got an identical npm-shrinkwrap.json in every system, that consistently builds across all of the RHEL/OSX/Windows8 systems and does not report SHA checksum issues anymore. It is beyond my understanding how it solved the issue.

In my issue, the main differences in npm-shrinkwrap.json came from the fsevents module's dependencies, where its embedded modules had their bundled attribute replaced by resolved and integrity attributes. I also had some differences on attributes "dev": true. Sample diff from the npm-shrinkwrap.json:

     "fsevents": {
       "version": "1.1.2",
       "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-1.1.2.tgz",
       "integrity": "sha512-Sn44E5wQW4bTHXvQmvSHwqbuiXtduD6Rrjm2ZtUEGbyrig+nUH3t/QD4M4/ZXViY556TBpRgZkHLDx3JxPwxiw==",
       "optional": true,
        "dependencies": {
          "abbrev": {
            "version": "1.1.0",
 -          "bundled": true,
 +          "resolved": "https://registry.npmjs.org/abbrev/-/abbrev-1.1.0.tgz",
 +          "integrity": "sha1-0FVMIlZjbi9W58LlrRg/hZQo2B8=",
            "optional": true
          },
          …

Hope this helps… Sorry for the noise, if my issue was not really linked to the one reported.

Update 14.06 (2/3): back to the Mac OSX and Windows 8 systems, with the freshly updated npm-shrinkwrap.json from the RHEL6 system, I get a checksum issue again:

$ npm install
npm WARN registry Unexpected warning for https://registry.npmjs.org/: Miscellaneous Warning EINTEGRITY: sha1-EyfXCZULVY8gTlNSWH/QKQ+Njkg= integrity checksum failed when using sha1: wanted sha1-EyfXCZULVY8gTlNSWH/QKQ+Njkg= but got sha512-mq0x3HCAGGmQyZXviOVe5TRsw37Ijy3D43jCqt/9WVf+onx2dUgW3PosnqCbScAFhRO9DGs8nxoMzU0iiosMqQ==. (68904 bytes)
…

What is quite confusing, is that this EINTEGRITY error message does not indicate which module has a checksum error: it only states the source registry https://registry.npmjs.org/.

Update 14.06 (1/3): solved the issue by deleting npm-shrinkwrap.json, re-running npm install on the RHEL6 system, and then npm shrinkwrap. It updated a few embedded dependencies to their latest versions, plus replaced some SHA1 checksums with SHA512, some other SHA512 with SHA1 checksums, and did not report any SHA checksum mismatch anymore on the RHEL6 system.

Not sure about the root cause and if it relates to this issue – may be you should ignore my comment hereafter. I'm still a bit confused of why the same npm-shrinkwrap.json (already in lockfile@v1 format of NPM v5) worked on Windows 8 and Mac OSX systems, and not the RHEL6 system, all of them running Node v8.0.1 and NPM v5.0.3.

Hello. I encountered the same problem on RHEL6, while trying to build an app that requires jsedn, which itself requires type-component: the later is not installed and the app fails to run. npm install reports following error on Red Hat Enterprise Linux 6:

npm WARN registry Unexpected warning for https://registry.npmjs.org/: Miscellaneous Warning EINTEGRITY: sha1-B5azH412iAB/8Lk6gIjTSqF8D3I= integrity checksum failed when using sha1: wanted sha1-B5azH412iAB/8Lk6gIjTSqF8D3I= but got sha512-h+8+r3MKEhkiVrwdKL8aWs1oc1VvBu33ueshOvS26RsZQ3Amhx/oO3TKe4lApSV9ueY6as8EAh7mtuFjdlhg9Q==. (23462 bytes)

No problem though for the exact same build on Windows 8.

Tried to clean my ~/.npm folder (rm -rf ~/.npm), same issue.

I hit this problem while experimenting with ProGet npm registries, which allowed me to publish the same package version multiple times (thus changing the hash). I solved it by deleting the package-lock.json (which may be named npm-shrinkwrap.json as in @olange's case), since I lock my packages in package.json anyway. npm install will then just recreate this when it runs again. Running npm cache clear --force won't hurt, but I don't think it's necessary.

I'm no expert, but I'm curious which package caused this. Can you look in your package-lock.json to see what package is associated with that integrity hash (sha1-Vx4PGwYEY268DfwhsDObvjE0FxA=)? It looks like the hashing method changed from SHA1 to SHA512, but I'm not sure how the method is determined.

@JonathonRichardson Hi Jonathon, the first packages with which I encountered these SHA1/SHA512 checksum warnings is type-component, and then a few others.

But the issue does not seem to be related to the checksums on the registry, rather with the way NPM calculates these checksums on different platforms.

I realized that depending on which system I was, npm shrinkwrap would produce SHA512 or SHA1 checksums, as well as it would change the placement of packages that are embedded in some other packages, are add or remove the "dev": true and "bundled": true attributes.

So, for me, it is either a platform dependent issue or, IMO more likely, what was available in the local cache on the different systems.

This is still broken. It fucks up checksums, and electron won't install correctly with npm version 5, you need to downgrade to 4 for it to work.

I also have a similar issue,

[ERROR] npm ERR! code EINTEGRITY
[ERROR] npm ERR! sha1-gswqb03PNvrPDHp5RoV7/2KCisc= integrity checksum failed when using sha1: wanted sha1-gswqb03PNvrPDHp5RoV7/2KCisc= but got sha1-U3cWwHduTPeePtG2IfdljCkRsbE=. (3344 bytes)

It would be pretty cool if it said for which package the checksum failed ... It fetches hundreds of packages and throws this in the middle. not very useful for debugging.

By the way, I run this in a docker image that doesn't have a cache (yet)

rm ./package-lock.json
rm -r ./node_modules
npm cache clear --force

That is the way i resolved this problem

I founded it at #7506 with the comment of @aliaksandr-master

@nguyentrucxinh your link is broken....

@luciagirasoles i fixed it, thank you!

@nguyentrucxinh shouldn't that 2nd line be rm -r ./node_modules ?

...since rm ./node_modules won't work on a non-empty directory
(as per https://askubuntu.com/a/217906 or similar)

...since rm ./node_modules won't work on a non-empty directory

It won't work on any directory, empty or not.

@nguyentrucxinh solution worked for me. Thanks.

I run into this problem when I'm using a react command: create-react-app, and it turned out as an ERROR. Then I delete all the node modules globally, then reinstall create-react-app, and everything works fine.
os: macos
how to remove all the modules: stackoverflow

npm ERR! code EINTEGRITY
npm ERR! sha1-+Osa0A3FilUUNjtBylNCgX8L1kY= integrity checksum failed when using
sha1: wanted sha1-+Osa0A3FilUUNjtBylNCgX8L1kY= but got sha1-gDAPSkPbqJMLsAVJA5AS
t+3CSiU=. (97776 bytes)

drag npm4 ,it sill bad

npm cache clear --force and npm install --no-shrinkwrap --update-binary resolved this issue for me.

I don't understand how people are suggesting removing the package-lock.json or npm-shrinkwrap.json is a solution. Yes, you may not get integrity warnings anymore, but you've also removed all the guarantees the lock/shrinkwrap was put in place to give you.

Unless I've missed something, I haven't seen any explanation by anyone as to why these warnings are happening in the first place?

I'm seeing this on a travis docker build, where I have a brand new node:8.9.4-alpine container on each build. Sometimes it happens, sometimes it doesn't. Just restarting the build (sometimes) fixes it, with exactly the same package.json and package-lock.json. Something is seriously broken here.

Which npm version is used? It is not happening here anymore. Also this might be a connection / network issue.

node:8.9.4-alpine is currently using npm v5.6.0. This happened to three of my travis-ci builds yesterday out of about... 20ish. Two back-to-back, another a few hours previously, with lots of successful builds inbetween.

What sort of connection/network issue did you have in mind? :)

So far all Travis builds with npm 5 do not have this issue, at least in the projects where I contribute to and watch the builds.

Are any of your projects on alpine, by any chance? I've run into enough other muslc weirdness in the past 24 hours than I'm perhaps overly suspicious. :P

Not sure but at least some of the docker containers use the Alpine distro afaik.

Happened to me twice today. Looking at the build, I notice a bunch of errors about missing files:

npm WARN deprecated CSSselect@0.4.1: the module is now available as 'css-select'
npm WARN deprecated CSSwhat@0.4.7: the module is now available as 'css-what'
npm WARN tar ENOENT: no such file or directory, lstat '/app/node_modules/.staging/moment-timezone-e8916734/data/unpacked'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/mousetrap-d5a23c7b/tests/libs/key-event.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/mousetrap-d5a23c7b/tests/libs/mocha-1.9.0.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/grpc-3f2a182e/deps/grpc/third_party/boringssl/crypto/cipher/test/aes_256_cbc_sha1_tls_tests.txt'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/reduce.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/context.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/chart.js-db360194/dist/Chart.bundle.min.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/schedule.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/catch_filter.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/settle.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/cancel.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/some.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/call_get.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/synchronous_inspection.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/bluebird.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/thenables.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/bind.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/timers.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/async.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/using.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/assert.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/util.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/map.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/grpc-66313728/deps/grpc/third_party/boringssl/include/openssl/thread.h'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/grpc-66313728/deps/grpc/third_party/boringssl/include/openssl/tls1.h'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/typescript-2d0ca0bc/lib/typescriptServices.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/lodash-486e720a/_createCaseFirst.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/lodash-486e720a/lodash.min.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/nyc-6e06d2b4/node_modules/handlebars/dist/handlebars.amd.min.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/moment-d30432dd/min/locales.min.js'
npm ERR! code EINTEGRITY
npm ERR! sha1-zgbdGxAS025boTS9QGt2JtTZt8U= integrity checksum failed when using sha1: wanted sha1-zgbdGxAS025boTS9QGt2JtTZt8U= but got sha1-nxrH1ykedriX/msSvvlF56ml8A0=. (48729 bytes)
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/fsevents-a1424645/node_modules/hawk/test/uri.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/fsevents-a1424645/node_modules/hawk/test/utils.js'
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2018-02-04T16_13_01_486Z-debug.log

Different missing files in each run.

I fixed this issue by completely removing npm and installing yarn

I fixed this issue by completely removing npm and installing yarn

This is not a fix.

For me the necessary steps were:

1. Clear cache on both build slave and local machine.
2. Get npm and node onto same versions on both machines.
3. Delete the package-lock.json file.
4. npm install on the local machine.
5. Commit and push new package-lock.json

Then it worked.

I was hit with the same EINTEGRITY error but for me it turned out to be my repo.

I'm using Nexus3 for the local repo & proxy of the main npm repo but it turned out the local metadata got corrupted. Version 1.8.0 was released on Monday (Feb 5) and upgrading it, invalidating the proxy & redeploying affected artefacts in the local repo fixed the problem.

I'm getting this warning when installing pm2 on an Ubuntu docker image, running on a Fedora host. It's docker, so the install is fresh, and should "just work".

I'm not a frequent node user, and experiences like this don't inspire confidence. Reliably delivering cryptographically verified packages across platforms and architectures seems like a pretty basic task for any package manager...

I have deleted, node_modules folder and packages.json.lock file.
Installed latest yarn.

yarn install <-- no errors ! instead of npm install.

Worked like a charm.

Lol, installing yarn is not a solution.

I've experienced the same thing as grantbrown above. Fresh install, npm --version 5.6.0 and node --version v8.10.0.

Experiences like this don't inspire confidence.

@ediweissmann 5.4.2 is my goto version for now. Very solid.

I only did "npm cache verify" and my problem was solved

@olange Thanks so much so much for the solution it really worked for me.

Downgrading to Node v6.14.2 worked for me

Downgrading to Node v6.14.2 worked for me

This probably cleared the caches. Try upgrading / downgrading npm.

So I have this issue, when package-lock.json is produced with npm@5.8.0, the npm install fails with npm@5.6.0 for SOME packages.

So just try to align the versions, it helps.

But still, I would like to know WHY this happens? Both 5.8.0 and 5.6.0 are using the same SHA algorithm.

Had the same issue - for me it had not been an issue with npm but with our private package repository (nexus 3.8). To reproduce it I used npm 6 + 3 but I assume it's the same with different npm 5 versions:

Reproduce:

1. npm publish samplePackage@1.2.3-SNAPSHOT with npm 6 (generates sha1 + sha512)
2. npm publish samplePackage@1.2.3-SNAPSHOT with npm 3 (generates only sha1)

The 2nd publish patches the package content and the sha1-checksum but our repository still kept the sha512 checksum.

Results:

• npm 3 ignores the sha512 and works as expected
• npm 6 will either use an old cached version (because it's still the old sha512) or throw an integrity error but will never use the updated SNAPSHOT
  (Even after removing package-lock.json and npm cache clean --force because the nexus still keeps the old sha512 value)

Solution:

a) Try always to publish packages with a npm version that generates the both checksums. (preferred)
b) Try never to publish packages with a npm version that generates the sha512 checksum.