cli
cli copied to clipboard
npm install removes resolved and integrity properties from package-lock.json if installed from cache
Is there an existing issue for this?
- [X] I have searched the existing issues
This issue exists in the latest npm version
- [X] I am using the latest npm
Current Behavior
If you run npm install with existing package cache inside "node_modules" it creates packages-lock.json without "resolved" and "integrity" properties.
Expected Behavior
"resolved" and "integrity" properties should stay remain after npm install using cache from "node_modules" folder
Steps To Reproduce
1.) Run npm install 2.) package-lock.json is created 3.) node modules are cached inside the project folder under "node_modules" folder 4.) delete package-lock.json and delete one package form "node_modules" folder 5.) Run npm install 6.) package-lock.json is created, but "resolved" and "integrity" properties are removed from each package descriptions inside package-lock.json
Environment
- npm: 8.1.2
- Node.js: 16.3.2
- OS Name: Windows 10
- System Model Name:
- npm config:
; copy and paste output from `npm config ls` here
In my case, it removes the resolved
entry for a company's remote repository, causing the CI pipeline to fail.
-
npm 8.1.3
-
node v16.3.0
- Mac OS
@giovannipds what about with npm v8.5.2?
@ljharb thanks for interacting. In my case, the issue was in my repository config, it was misconfigured, that's why my resolved
s were being removed. Probably not related to what this ticket is about. What fixed for me:
npm config set registry #YOUR_COMPANY_REGISTRY_URL
I managed to get proper package-lock.json
(with integrity
and resolve
fields) after:
- cleaning the npm cache
npm cache clean -f
- removing
node_modules
in project folder - removing the
package-lock.json
file - running
npm install
in now "clean" project folder
Just ran into this issue on npm 8.19.2
with node v18.12.1
.
Cleared the cache and re-ran npm install
(slow), then it was ok
I encountered the same issue with nodejs 16.19.1
and npm 8.19.3
encountered the same issue with node 14.18.0
and npm 8.19.3
Happened on npm v9.5.0
too. vmasek
s workaround worked.
We also get this. Repeatedly. And it breaks our CI. Started after we updated to new versions of node and npm recently I think, but I see others get it on older versions as well. I'm not 100% if that is what cased it, as we have refactored a lot of stuff lately. Current versions: Node: 18.16.0 npm: 9.6.7 old versions: Node: 16.5.1 npm: not sure unfortunately, but v8.x.x something
Only workaround is @vmasek workaround above. Would love to not have to delete package-lock.json
the whole time, any idea whats causing this or if/when it will be fixed?
For those who dislike the idea of unlocking and potentially version-bumping a ton of dependencies by deleting package-lock, here's a variant of the workaround above that seems to have worked for us:
- Delete
node_modules
folder - Restore
package-lock.json
from a recent commit prior to the undesired property removal (but keep the existingpackage.json
version) - Run
npm install
This should preserve the locked versions of any packages that were already installed prior to the corruption of package-lock, while ensuring anything newer based on package.json
also gets installed/updated.
I had this happened to me during npm solving merge conflicts with npm-merge-driver
. Similarly to @rbell-mfj, I restored package-lock.json before merge conflict resolution, applied the updates manually, integrity and resolved were kept.
I faced the same problem with node 18.12.1 and npm 8.19.2 Had to do actions proposed by vmasek to resolve the problem.
While this problem persists, npm-lockfile-fix provides an easy way to fix lock files without having to delete & regenerate them. It's less problematic since it doesn't cause any dependency updates.
Also it seems that these are duplicates or related issues: #4460 #6301
Seeing this with node 20.9.0 and NPM 10.2.1. Workaround from vmasek worked for me, too.
Also seeing this in node 18.18.2 and npm 9.8.1
I wonder if the npm team will ever pick this issue up? It's still happening.
Has this issue today, solved it with running npm cache clear --force
(not sure if this was useful) and npm update
.
.. solved it with ...
npm update
.
npm update
, or deleting package-lock.json then npm install
, IMHO defeats the purpose of package-lock.json and can cause issues downstream (different dependency versions, failing tests, failing deploys, bugs...).
We have package-lock.json change 'randomly' after npm install
from different developers. All on the same (at least major) version, causing CI delays (busted cache). Would love to see this solved.
.. solved it with ...
npm update
.
npm update
, or deleting package-lock.json then npm install
, IMHO defeats the purpose of package-lock.json and can cause issues downstream (different dependency versions, failing tests, failing deploys, bugs...).
We have package-lock.json change 'randomly' after npm install
from different developers. All on the same (at least major) version, causing CI delays (busted cache).
So, our problem is similar albeit not related to deleting package-lock.json (which we do not recommend every anyway): Subsequent npm install
s on different machines change package-lock.json "resolved" and "integrity" entries. Would love to see this solved.
.. solved it with ...
npm update
.
npm update
, or deleting package-lock.json thennpm install
, IMHO defeats the purpose of package-lock.json and can cause issues downstream (different dependency versions, failing tests, failing deploys, bugs...). We have package-lock.json change 'randomly' afternpm install
from different developers. All on the same (at least major) version, causing CI delays (busted cache). So, our problem is similar albeit not related to deleting package-lock.json (which we do not recommend every anyway): Subsequentnpm install
s on different machines change package-lock.json "resolved" and "integrity" entries. Would love to see this solved.
This might be a dumb suggestion, but couldn't you just ask your developers not to change the package-lock
? For example, tell them to use npm ci
on their dev machines instead of npm install
unless they are intentionally updating packages.