Open JsweetA opened 1 month ago
@JsweetA Could you please try with--os
flag to see if it fits this case. https://docs.npmjs.com/cli/v10/commands/npm-install#os
@JsweetA Could you please try with
--os
flag to see if it fits this case. https://docs.npmjs.com/cli/v10/commands/npm-install#os
Does it mean to use npm i --os=linux
? If so, it doesn't solve my problem.
@JsweetA I think what's happening here is that first time it's constructing the lock file based on package.json information. then once you delete the lock file it's reconstructing lock file base on what is in the node_modules. As far as I know we have smiler issue where integrity field is missing after deleting and recreating lock file iirc that is also the same cause. but if you check in both the cases it's installing same packages. you can verify that using npm ls --depth=2
before and after your steps.
Likely duplicate of #4828
Deleting package-lock.json causes so many differences after npm installing again, even though if you use specific versions instead of versions like "^2.1.0", or you may be using latest version of all packages but still it generates very different package-lock
Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
I used a node-unix-socket package, which needs to load different .node files under different system architectures. I accidentally deleted the lock file when operating on my local Mac computer. When I used npm i to install it again, the lock file only had packages under the Mac architecture. This would cause the package to be lost when I released the deployment because the container used the Linux architecture.
Expected Behavior
Yarn and pnpm do not have this problem. They do not rely on node_modules to generate lock files, so the generation of lock files is idempotent. However, when there are packages that depend on the system architecture, the generation of lock files by npm i is not idempotent.
Steps To Reproduce