New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Platform-specific optional dependencies not being included in package-lock.json
when reinstalling with node_modules
present
#4828
Comments
node_modules
present
node_modules
presentpackage-lock.json
when reinstalling with node_modules
present
Sorry to ping you out of the blue, but this issue has been open for 11 days now without any movement. Is there anyone working on npm right now that might have the bandwidth to at least validate that this is indeed a problem as I've described it? Just so that when someone does become available to do some development work they know that this is in the queue? Please and thank you. |
Bump |
I'm also encountering this issue with a Next.js project:
Unfortunately developers often don't realise the Here is a reproduction:
|
I am also having this issue. I'm trying to run tests using jest with swc. The test runner is a linux image, but my dev machine is darwin. I can get it to work by either using --force to install the linux dependency, or I can install packages from inside the container... but github CI stands up the docker container in such a way that I can't easily install packages from in there, and that also prevents me from maintaining a cached node modules etc. |
bump |
bump - cannot get optional dependencies (namely |
bump |
Confirming that this issue is still present. It's particularly important for projects using NAPI modules, as tons of them use platform-specific packages. |
Ran into this issue when creating a CI process for a repo where I use a Windows machine and the CI process is using Linux. My quick "fix" for now is to start the CI process by deleting the package-lock.json and running npm install instead of npm ci. I know this is not good practice, so looking forward to a real fix to come through. |
bump |
I am having a similar issue. My project uses What has changed between v6 and v8 and is there an npm config option that will have v8 work similar to v6 when it comes to optional dependencies? |
Error: Cannot find module @rollup/rollup-darwin-arm64. npm has a bug related to optional dependencies (npm/cli#4828)
to fix @nx (@rollup or others) optional deps inside package-lock.json, i downgraded npm to 6 version and removed lock.json. then npm install. then returned newer version of npm and again npm i. now i have perfect nx optional deps inside lock.json. and i do not have extra/unwanted optionalDependencies in package.json |
Ran into this issue with Vite + node 18.20.1/npm 10.5.0. Clearing node_modules and package-lock.json then reinstalling with node 16.20.1/npm 8.19.4 worked correctly. |
It seems that an npm issue causes build problems related to a divergence in node_modules and package-lock.json: npm/cli#4828 I hope this change will fix this.
I'm also experiencing a problem related to when using angular/cli Error: Cannot find module @rollup/rollup-android-arm64. npm has a bug related to optional dependencies (#4828). Please try Node.js v21.6.2` Deleting |
Deleting the lock file and node_modules directory, and then running npm i, worked for me 🚀 |
Please stop posting this. It isn't a solution. For many of us regenerating the lockfile isn't an option because it causes a lot of packages to be upgraded to broken versions. And running this for one teammate with a certain architecture breaks it for other teammates with different architectures. |
@mctrafik and others: If regenerating your node_modules leads to broken packages, then you have that problem to fix outside of the problem in this bug. You should always be able to start from scratch (i.e. delete node_modules and reinstall and have a working project). It may require better / more specific version specifications for example. That doesn't mean it's a valid fix for this bug. And it is a very large pain to have to run regularly. So I don't advocate for it as a solution, but it is a sign of a broken project already if it isn't possible. |
@mctrafik Well, it's not the complete solution, but not all of us encounter issues with regenerating the lockfile. |
@localpcguy very well said. #4828 (comment) is the correct answer - it's not a solution, but it should always be an available workaround, or else your dep graph is invalid. Fix that. |
@localpcguy in a CI and a industrialization process, this is not an option. |
I'm happy for the people with the luxury of just regenerating the lock file but if your build and deploy processes require a lock file and your architecture is incompatible with your deployment architecture you'll still have this problem. Deleting the lock file is not recommended and it shouldn't be proposed as a "solution" to this problem for the 50th time in this discussion. Adding some optional dependencies is not a real solution either as that will also fail in the scenario above. There's an actual bug here and it's not being fixed. I have no idea why. |
I did this #4828 (comment) and it worked me |
Telling people here that they shouldn't fully rely on lockfiles to lock their package versions is sort of like critiquing someone whose engine is on fire because their lug nuts are not torqued correctly: Not technically wrong, but not really helping with the problem. More seriously, we should be mindful about suggesting recreating it as a workaround because it's going to lead to different devs on different hardware constantly deleting / recreating the lock file as it thrashes around between platform versions, and it won't work in a lot of deployment scenarios. It pretty much defeats the purpose of the lockfile and creates a lot of busywork & large diffs, assuming it doesn't just break prod deploys. It might function for some in a pinch but they haven't actually worked around the problem, they've just hidden it by tieing the lockfile to their current platform... I am also surprised this one has been here for almost two years with radio silence since it is a somewhat breaking bug. |
Since we have 2nd anniversary, is there any progress on that issue? |
Are there any progress to be seen? |
Are there any progress to be seen ? i just encountered this problem,the tip in the console |
|
Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
I'm working on a team that utilizes a mix of x64-based and m1-based macs, and has CI build processes that uses musl. We're seeing that
npm
is skipping platform-specific optional dependencies for packages such as@swc/core
as a result of thepackage-lock.json
file being generated without all of them included. In our case, this then causes linting to throw an exception, because one of our eslint plugins depends on @swc, which depends on having the platform specific @swc package also installed.There seems to be at least two stages of cause to this. Firstly, when installing
@swc/core
from a clean slate working directorynpm
generates apackage-lock.json
with all of the optional dependencies for@swc/core
listed:And it only installs the platform specific package:
If I then remove my
package-lock.json
, leave mynode_modules
directory as-is, and then reinstall, I get:That is, it then generates a package-lock.json with only the platform-specific dependency that was installed on this machine, and not with the other optional dependencies that should also be listed.
If you delete both
node_modules
ANDpackage-lock.json
, and then re-runnpm install
, it generates the correct lockfile with all of those optional dependencies listed.The problem is that then, If the
package-lock.json
with the missing optional platform-specific dependencies gets checked into git and an x64 user pulls it down, or vice-versa,npm
fails to detect that your platform's optional dependencies are missing in the lockfile and just silently skips installing the platform-specific dependency. For example, when I've got a package-lock.json that only contains the x64 @swc package because of the above problem (generated by my coworker on his x64 machine):And I then install:
You can see that it fails to install the arm64 dependency or warn me in any way that the
package-lock.json
is missing my platform's dependency.So yeah, two problems:
Expected Behavior
npm
should preserve the full set of platform-specific optional deps for a package like @swc when rebuildingpackage-lock.json
from an existingnode_modules
treenpm install
should warn if thepackage-lock.json
becomes inconsistent because of the first caseSteps To Reproduce
See above.
Environment
The text was updated successfully, but these errors were encountered: