issue: npm install produces different lockfiles on different computes

Hi I’m continuing this from github https://github.com/npm/npm/issues/16938
I’m running the latest npm (6.7.0) in my mac and in my production server (CentOS 7), and I’m still experiencing this issue.

npm install is generating differences in package-lock.json using SHA1 on one computer and SHA512 on the other.

Here is a portion of git diff, the only difference is the integrity hash while version numbers remain the same.

@@ -260,7 +260,7 @@
     "asn1.js": {
       "version": "4.10.1",
       "resolved": "https://registry.npmjs.org/asn1.js/-/asn1.js-4.10.1.tgz",
-      "integrity": "sha512-p32cOF5q0Zqs9uBiONKYLm6BClCoBCM5O9JfeUSlnQLBTxYdTK+pW+nXflm8UkKd2UYlEbYz5qEi0JuZR9ckSw==",
+      "integrity": "sha1-ucK/WAXx5kqt7tbfOiv6+1pz9aA=",
       "requires": {
         "bn.js": "^4.0.0",
         "inherits": "^2.0.1",
@@ -326,7 +326,7 @@
     "atob": {
       "version": "2.1.2",
       "resolved": "https://registry.npmjs.org/atob/-/atob-2.1.2.tgz",
-      "integrity": "sha512-Wm6ukoaOGJi/73p/cl2GvLjTI5JM1k/O14isD73YML8StrH/7/lRFgmg8nICZgD3bZZvjwCGxtMOD3wWNAu8cg=="
+      "integrity": "sha1-bZUX654DDSQ2ZmZR6GvZ9vE1M8k="
     },
     "autoprefixer": {
       "version": "7.1.6",
@@ -1170,7 +1170,7 @@
     "base": {
       "version": "0.11.2",
       "resolved": "https://registry.npmjs.org/base/-/base-0.11.2.tgz",
-      "integrity": "sha512-5T6P4xPgpp0YDFvSWwEZ4NoE3aM4QBQXDzmVbraCkFj8zHM+mba8SyqB5DbZWyR7mYHo6Y7BdQo3MoA4m0TeQg==",
+      "integrity": "sha1-e95c7RRbbVUakNuH+DxVi060io8=",
       "requires": {
         "cache-base": "^1.0.1",
         "class-utils": "^0.3.5",
@@ -1192,7 +1192,7 @@
         "is-accessor-descriptor": {
           "version": "1.0.0",
           "resolved": "https://registry.npmjs.org/is-accessor-descriptor/-/is-accessor-descriptor-1.0.0.tgz",
-          "integrity": "sha512-m5hnHTkcVsPfqx3AKlyttIPb7J+XykHvJP2B9bZDjlhLIoEq4XoK64Vg7boZlVWYK6LUY94dYPEE7Lh0ZkZKcQ==",
+          "integrity": "sha1-FpwvbT3x+ZJhgHI2XJsOofaHhlY=",
           "requires": {
             "kind-of": "^6.0.0"
           }

After you do npm update, please rm -rf node_modules package-lock.json && npm cache clear -f and try this again. Can you still reproduce it after this?

1 Like

yes, this fixed the issue. Thanks!

1 Like

Best I can do, Kat, is to call it a workaround. I’m afraid this resolves the problem for a short while and/or for a limited number of packages. Whenever something changes in package-lock.json, like someone from the team installs a new package, this issue comes back and after npm install I see integrity hashes changed from sha512 to sha1 in numerous places.

The only thing working for me is:

  • Removing all sha1 integrity hashes from package-lock.json
  • and executing:
    npm cache clean -f
    rm -rf node_modules
    npm i
    

This always resolves the issue, but also it always comes back after a while.

This issue happens on many computers in our team. Currently we forcibly clean the npm cache with automatic script before install, but I think we can agree this is not ideal.

It seems to me you also need to delete package-lock.json once and generate it with the newer npm version then it won’t come back. Zkat’s answer worked for me and it hasn’t come back. Maybe someone in your team has a different npm version?

Edited my previous comment to state that I need to remove sha1 integrity hashes before executing these to make it work. I guess removing package-lock.json would work as well.

Anyway - nope, everyone is always up to date. We added updating npm to preinstall as well. I’m randomly getting sha512 hashes replaced with sha1 all the time.

Deleting node_modules and clearing cache does not help me. I still get sha1 instead of sha512 in lock file after running npm i. What is also weird is that after updating some versions in package.json all new updated versions got sha512 (thanks god) and some packages (but not all) that did not change version got their integrity hash degraded to sha1. So now I have:

  1. Updated and new packages with sha512 (one of them has been upgraded from sha1).
  2. Unchanged packages with sha512.
  3. Unchanged packages with sha1.
  4. Packages with unchanged version but with integrity downgraded from sha512 to sha1.

It seems to be a bug.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.