npm install produces different lockfiles on different computes

[ianwremmel]

I'm opening this issue because:

• npm is crashing.
• npm is producing an incorrect install.
• npm is doing something I don't understand.
• Other (see below for feature requests):

What's going wrong?

How can the CLI team reproduce the problem?

I'm running npm install against the same SHA of the same repo on two different computes. One computer installs as expected and produces no changes. The other computer installs as expected but produces the diff below.

diff --git a/package-lock.json b/package-lock.json
index d09cba3..215d709 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -150,7 +150,7 @@
         "glob": {
           "version": "7.1.2",
           "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.2.tgz",
-          "integrity": "sha1-wZyd+aAocC1nhhI4SmVSQExjbRU=",
+          "integrity": "sha512-MJTUg1kjuLeQCJ+ccE4Vpa6kKVXkPYJ2mOCQyUuKLcLQsdrMCpBPUi8qVE6+YuaJkozeA9NusTAw3hLr8Xe5EQ==",
           "dev": true
         }
       }
@@ -164,7 +164,7 @@
         "glob": {
           "version": "7.1.2",
           "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.2.tgz",
-          "integrity": "sha1-wZyd+aAocC1nhhI4SmVSQExjbRU=",
+          "integrity": "sha512-MJTUg1kjuLeQCJ+ccE4Vpa6kKVXkPYJ2mOCQyUuKLcLQsdrMCpBPUi8qVE6+YuaJkozeA9NusTAw3hLr8Xe5EQ==",
           "dev": true
         }
       }
@@ -326,7 +326,7 @@
         "glob": {
           "version": "7.1.2",
           "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.2.tgz",
-          "integrity": "sha1-wZyd+aAocC1nhhI4SmVSQExjbRU=",
+          "integrity": "sha512-MJTUg1kjuLeQCJ+ccE4Vpa6kKVXkPYJ2mOCQyUuKLcLQsdrMCpBPUi8qVE6+YuaJkozeA9NusTAw3hLr8Xe5EQ==",
           "dev": true
         },
         "source-map": {
@@ -1648,7 +1648,7 @@
         "glob": {
           "version": "7.1.2",
           "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.2.tgz",
-          "integrity": "sha1-wZyd+aAocC1nhhI4SmVSQExjbRU=",
+          "integrity": "sha512-MJTUg1kjuLeQCJ+ccE4Vpa6kKVXkPYJ2mOCQyUuKLcLQsdrMCpBPUi8qVE6+YuaJkozeA9NusTAw3hLr8Xe5EQ==",
           "dev": true
         },
         "strip-bom": {
@@ -2966,7 +2966,7 @@
         "glob": {
           "version": "7.1.2",
           "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.2.tgz",
-          "integrity": "sha1-wZyd+aAocC1nhhI4SmVSQExjbRU=",
+          "integrity": "sha512-MJTUg1kjuLeQCJ+ccE4Vpa6kKVXkPYJ2mOCQyUuKLcLQsdrMCpBPUi8qVE6+YuaJkozeA9NusTAw3hLr8Xe5EQ==",
           "dev": true
         },
         "object-assign": {
@@ -2986,7 +2986,7 @@
         "glob": {
           "version": "7.1.2",
           "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.2.tgz",
-          "integrity": "sha1-wZyd+aAocC1nhhI4SmVSQExjbRU=",
+          "integrity": "sha512-MJTUg1kjuLeQCJ+ccE4Vpa6kKVXkPYJ2mOCQyUuKLcLQsdrMCpBPUi8qVE6+YuaJkozeA9NusTAw3hLr8Xe5EQ==",
           "dev": true
         },
         "lodash": {
@@ -3983,7 +3983,7 @@
     "minimatch": {
       "version": "3.0.4",
       "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.0.4.tgz",
-      "integrity": "sha1-UWbihkV/AzBgZL5Ul+jbsMPTIIM="
+      "integrity": "sha512-yJHVQEhyqPLUTgt9B83PXu6W3rx4MvvHvSUvToogpwoGDOUQ+yDrR0HRot+yOCdCO7u4hX3pWft6kWBBcqh0UA=="
     },
     "minimist": {
       "version": "0.0.10",
@@ -4220,7 +4220,7 @@
         "glob": {
           "version": "7.1.2",
           "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.2.tgz",
-          "integrity": "sha1-wZyd+aAocC1nhhI4SmVSQExjbRU=",
+          "integrity": "sha512-MJTUg1kjuLeQCJ+ccE4Vpa6kKVXkPYJ2mOCQyUuKLcLQsdrMCpBPUi8qVE6+YuaJkozeA9NusTAw3hLr8Xe5EQ==",
           "dev": true
         }
       }
@@ -4308,7 +4308,7 @@
     "npmlog": {
       "version": "4.1.0",
       "resolved": "https://registry.npmjs.org/npmlog/-/npmlog-4.1.0.tgz",
-      "integrity": "sha1-3Fm+6F9k8A7UJO+yrweD3yXRwLU=",
+      "integrity": "sha512-ocolIkZYZt8UveuiDS0yAkkIjid1o7lPG8cYm05yNYzBn8ykQtaiPMEGp8fY9tKdDgm8okpdKzkvu1y9hUYugA==",
       "dev": true
     },
     "number-is-nan": {
@@ -5031,7 +5031,7 @@
         "glob": {
           "version": "7.1.2",
           "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.2.tgz",
-          "integrity": "sha1-wZyd+aAocC1nhhI4SmVSQExjbRU=",
+          "integrity": "sha512-MJTUg1kjuLeQCJ+ccE4Vpa6kKVXkPYJ2mOCQyUuKLcLQsdrMCpBPUi8qVE6+YuaJkozeA9NusTAw3hLr8Xe5EQ==",
           "dev": true
         }
       }
@@ -5187,7 +5187,7 @@
         "glob": {
           "version": "7.1.2",
           "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.2.tgz",
-          "integrity": "sha1-wZyd+aAocC1nhhI4SmVSQExjbRU=",
+          "integrity": "sha512-MJTUg1kjuLeQCJ+ccE4Vpa6kKVXkPYJ2mOCQyUuKLcLQsdrMCpBPUi8qVE6+YuaJkozeA9NusTAw3hLr8Xe5EQ==",
           "dev": true
         }
       }
@@ -5814,7 +5814,7 @@
         "glob": {
           "version": "7.1.2",
           "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.2.tgz",
-          "integrity": "sha1-wZyd+aAocC1nhhI4SmVSQExjbRU=",
+          "integrity": "sha512-MJTUg1kjuLeQCJ+ccE4Vpa6kKVXkPYJ2mOCQyUuKLcLQsdrMCpBPUi8qVE6+YuaJkozeA9NusTAw3hLr8Xe5EQ==",
           "dev": true
         },
         "inquirer": {
@@ -5888,7 +5888,7 @@
     "wide-align": {
       "version": "1.1.2",
       "resolved": "https://registry.npmjs.org/wide-align/-/wide-align-1.1.2.tgz",
-      "integrity": "sha1-Vx4PGwYEY268DfwhsDObvjE0FxA=",
+      "integrity": "sha512-ijDLlyQ7s6x1JgCLur53osjm/UXUYD9+0PbYKrBsYisYXzCxN+HC3mYDNy/dWdmf3AwqwU3CXwDCvsNgGK1S0w==",
       "dev": true
     },
     "window-size": {

supporting information:

• npm -v prints: 5.0.2
• node -v prints: v7.10.0
• npm config get registry prints: https://registry.npmjs.org/
• Windows, OS X/macOS, or Linux?: macOS 10.12.4
• Network issues:
  • Geographic location where npm was run:
  • I use a proxy to connect to the npm registry.
  • I use a proxy to connect to the web.
  • I use a proxy when downloading Git repos.
  • I access the npm registry via a VPN
  • I don't use a proxy, but have limited or unreliable internet access.
• Container:
  • I develop using Vagrant on Windows.
  • I develop using Vagrant on OS X or Linux.
  • I develop / deploy using Docker.
  • I deploy to a PaaS (Triton, Heroku).

[ianwremmel]

Interestingly, deleting node modules and installing everything from scratch made the problem go away.

[adamjmurray]

My team encountered this behavior, and deleting node_modules and reinstalling cleared up the problem.

I suspect a mismatch was introduced between package-lock and the individual node_module's integrity field, because some of my teammates are switching between a branch using Node 6 / npm 4 and a branch using Node 8 / npm 5.

In this case, I expected npm 5 to update my node_modules to match the package-lock, rather than modify the integrity fields inside the package-lock to match the currently installed node_modules.

[gillesdemey]

@zkat Any pointers on where to start looking? Might be able to make some time to track this down :)

[Raigen]

Deleting node_modules does not solve this issue for me.
Our package-lock.json was generated on a Mac, I am using Windows 10. Another colleague with Windows 10 does not have the same issue. Like this I am not able to contribute new dependencies to the project because it will not just add new packages to packages-lock.json but also changes all integrity fields in the whole file. Why is it changing the package-lock.json in the first place? And why is it producing different files on different systems? This is not the way a lock-file should behave.

I completly removed and reinstalled npm and node. I removed <user>/AppData/Roaming/npm and <user>/AppData/Roaming/npm-cache and still have the problem that npm i is changing all integrity fields in the package-lock.json. This way we still can not switch to npm@5. It is already on version 5.3.0 and still not usable at all it seems.

$ node -v
v8.4.0
$ npm -v
5.3.0

$ git diff
[...]
@@ -1398,7 +1398,7 @@
     "babel-preset-env": {
       "version": "1.6.0",
       "resolved": "https://registry.npmjs.org/babel-preset-env/-/babel-preset-env-1.6.0.tgz",
-      "integrity": "sha512-OVgtQRuOZKckrILgMA5rvctvFZPv72Gua9Rt006AiPoB0DJKGN07UmaQA+qRrYgK71MVct8fFhT0EyNWYorVew==",
+      "integrity": "sha1-LeHHgqeAoKXWBdGZyVdZbaQ8ROQ=",
       "dev": true,
       "requires": {
         "babel-plugin-check-es2015-constants": "6.22.0",
@@ -1549,7 +1549,7 @@
     "babylon": {
       "version": "6.17.4",
       "resolved": "https://registry.npmjs.org/babylon/-/babylon-6.17.4.tgz",
-      "integrity": "sha512-kChlV+0SXkjE0vUn9OZ7pBMWRFd8uq3mZe8x1K6jhuNcAFAtEnjchFAqB+dYEXKyd+JpT6eppRR78QAr5gTsUw==",
+      "integrity": "sha1-Pot0AriNIsNCPhN6FXeIOxX/hpo=",
       "dev": true
     },
     "balanced-match": {
@@ -1560,7 +1560,7 @@
     "base64-js": {
       "version": "1.2.1",
       "resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.2.1.tgz",
-      "integrity": "sha512-dwVUVIXsBZXwTuwnXI9RK8sBmgq09NDHzyR9SAph9eqk76gKK2JSQmZARC2zRC81JC2QTtxD0ARU5qTS25gIGw==",
+      "integrity": "sha1-qRlH2h9KUW6jjltOwOw3c2deCIY=",
       "dev": true
     },
     "base64url": {
@@ -1650,7 +1650,7 @@
[...]

[Butterfly]

Where @Raigen says:

Like this I am not able to contribute new dependencies to the project because it will not just add new packages to packages-lock.json but also changes all integrity fields in the whole file.

Could you please give me a better idea of what is changing?

This may be moot (non-existent) now because I upgraded last night, but I was having a problem with dependencies removing each other REPEATEDLY.

If it happens again, I could compare what mine is doing to what @Raigen has seen to see if the same or similar is happening in my case. My problem is that I am so new, I don't know what is normal or to be expected versus the system wrongly editing files.

Thank you in advance if anyone has any tips 😄

[yelworc]

FWIW, I had the same issue (integrity field flipping between sha1 and sha512 values on new module installation) between two different Debian systems (stretch and jessie), both using npm 5.3.0. Deleting the contents of node_modules and running npm i on both systems fixed the problem for me as well.

[bjester-ss]

My team is having a similar issue. We're all on Fedora 26 using the same node -v and npm -v, but running an install we're producing differing package-lock.json. We've tried removing node_modules and doing a clean install to no avail.

[drewlustro]

I'm also having this issue.

MacOS 10.11 produces a sha1 integrity, whereas Ubuntu 17.10 produces a sha512 integrity hash, thus busting the package-lock.json file and creating a ton of noise.

Both machines have:

npm version = 5.4.2
node version = 7.10.1

[BrendanFDMoore]

Im seeing this as well, not sure where it's coming from.

npm 5.4.2, node 8.6.0, osx 10.12

[ghost]

We're also seeing this.

The one machine prefers sha512, the other sha1.

Both machines: npm 5.3.0, node 8.6.0, Windows 10.

[BrendanFDMoore]

For our team, this appears to have resolved the issue (or its current incarnation, at least):

1. Ensure matching node/npm versions as a team: node -v and npm -v (and install matching versions if different)
2. Remove your node modules: rm -rf node_modules/
3. Clean your npm cache: npm cache clean --force
4. Revert the changes in your package-lock.json file (and this file only).
5. Install dependencies again: npm i

While this might be a bit heavy handed, it did solve the issue I was seeing and the integrity hash diffs went away.

Other reporters can try this and share results. Maybe we can learn more about the root cause.

[ghost]

We ran through that procedure and the two machines now keep the lock file in sync.

npm 5.4.2, node 8.8.1.

[rainboxx]

@AndyCJ Do you mean the procedure from @BrendanFDMoore?

[ghost]

@rainboxx Yep.

[uptownnickbrown]

+1 what @BrendanFDMoore suggested worked here as well.

Two Mac machines, npm 5.5.1, node 6.12.0.

[thijstriemstra]

I'm surprised this kind of bug creeped in, isn't this bound to happen to a 'lockfile' and easy to test?

[BrendanFDMoore]

Is anybody else experiencing this on a project which includes packages from a private npm repo/proxy?

Of all the things I'm working on, that project is the only one where I see this happen.

[patrickhousley]

Hey maintainers. Thanks for the hard work. I was just wondering if this was fixed with the 5.6 release and, if not, is there a timeline.

[rainboxx]

We saw it fixed when we upgraded to 5.5.1. No issues since then anymore, but we had to delete all node_modules folders and do a fresh install. See also: #16938 (comment)

[drewlustro]

@patrickhousley - I can verify this is fixed as long as you follow instructions by @BrendanFDMoore

npm@5.6

[zkat]

This should be resolved as of npm@5.6. You may need to start fresh with the steps mentioned in #16938 (comment) but it might be fine even without that now. Give it a whirl. I believe the core issue (accidentally defaulting to sha1 in some cases) has been resolved now, so I'm gonna close this. Cheers.

[uptownnickbrown]

@brad I see a mix of sha1 and sha256 in the resolved file, but it looks like I only see sha256 being used for any new hashes.

See this commit + diff: MetaSeek-Sequencing-Data-Discovery/metaseek@266609c#diff-a357eeafe4d42d4d291125cb288f2cee

Existing hashes were unchanged (and they were sha1's) but new hashes all used sha256 (eg. line 71).

[brad]

Thanks @uptownnickbrown, that's super helpful 👍

[marekr]

Node 8.9.4 and npm 5.6.0 both fresh on a Windows 10 and Windows Server 2016 machine.

Npm on Windows 10 is generating sha1 hashes in a brand new package-lock file.

Npm on the windows server is updating the package-lock file on npm install to sha512.

What the bloody duck?

[Wirone]

node v9.4.0
npm 5.6.0

Got sha1 hashes instead of sha512 when I was developing Rocket.Chat locally, installed packages and THEN used npm install <package> --save. After removing node_modules and running npm install again, I got only my new package in package-lock.json's diff.

[rainboxx]

If you face this issue, please follow the instructions from this comment #16938 (comment).

[DimaRGB]

you can check this steps, at least it works for me: https://gist.github.com/DimaRGB/5482e1e8bd3cc82d97511b65a2ae44a2

[alanmanderson]

I think it is worth noting that on our project, we have fought with this for quite a while which has resulted in our package-lock file containing some sha1 hashes and some sha512. Now pull requests that change the package-lock file, have the hash switching regardless to which has was used.

For example the below changes are from the same PR. Notice the first one goes from sha512 to sha1 and the second does the opposite:

-      "integrity": "sha512-Y+c3F4eM6BwVWH4AFK3kQXfrRgi5OjaUCfc+vgzCNXtGipNrOmBYN9LHTD0W2ssSzmCBZLw2fniy/gF2pJAadA=="
+      "integrity": "sha1-+JJWHPqZSrqqKxdO1vKDrZ6qxVU="
...
-      "integrity": "sha1-+PLIh60Qv2f2NPAFtph/7TF5qsg="
+      "integrity": "sha512-nne9/IiQ/hzIhY6pdDnbBtz7DjPTKrY00P/zvPSm5pOFkl6xuGrGnXn/VtTNNfNtAfZ9/1RtehkszU9qcTii0Q=="

[zkat]

I'm going to consider this resolved based on previous messages, and I have to emphasize that in order to fully clear it up, you'll need to follow #16938 (comment).

If you're still experiencing this on the latest version of npm (npm i -g npm@latest), feel free to file a new bug report in npm.community, which is where we're going to be moving our support stuff.

In the meantime, I'm gonna lock this to prevent future confusion.