[BUG] Platform-specific optional dependencies not being included in `package-lock.json` when reinstalling with `node_modules` present

[JustinChristensen]

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

[user@host:foo] $ npm -v
8.8.0
[user@host:foo] $ node
Welcome to Node.js v16.14.2.
Type ".help" for more information.
> process.arch
'arm64'

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 the package-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 directory npm generates a package-lock.json with all of the optional dependencies for @swc/core listed:

[user@host:foo] $ npm install @swc/core
[user@host:foo] $ grep 'node_modules/@swc/core-*' package-lock.json
    "node_modules/@swc/core": {
    "node_modules/@swc/core-android-arm-eabi": {
    "node_modules/@swc/core-android-arm64": {
    "node_modules/@swc/core-darwin-arm64": {
    "node_modules/@swc/core-darwin-x64": {
    "node_modules/@swc/core-freebsd-x64": {
    "node_modules/@swc/core-linux-arm-gnueabihf": {
    "node_modules/@swc/core-linux-arm64-gnu": {
    "node_modules/@swc/core-linux-arm64-musl": {
    "node_modules/@swc/core-linux-x64-gnu": {
    "node_modules/@swc/core-linux-x64-musl": {
    "node_modules/@swc/core-win32-arm64-msvc": {
    "node_modules/@swc/core-win32-ia32-msvc": {
    "node_modules/@swc/core-win32-x64-msvc": {

And it only installs the platform specific package:

[user@host:foo] $ ls -l node_modules/@swc/
total 0
drwxr-xr-x  22 user  staff  704 Apr 29 15:39 core
drwxr-xr-x   6 user  staff  192 Apr 29 15:39 core-darwin-arm64

If I then remove my package-lock.json, leave my node_modules directory as-is, and then reinstall, I get:

[user@host:foo] $ rm -rf package-lock.json
[user@host:foo] $ npm install
[user@host:foo] $ grep 'node_modules/@swc/core-*' package-lock.json
    "node_modules/@swc/core": {
    "node_modules/@swc/core-darwin-arm64": {

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 AND package-lock.json, and then re-run npm 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):

[user@host:foo] $ node
Welcome to Node.js v16.14.2.
Type ".help" for more information.
> process.arch
'arm64'
>
[user@host:foo] $ grep 'node_modules/@swc/core-*' package-lock.json
    "node_modules/@swc/core": {
    "node_modules/@swc/core-darwin-x64": {
[user@host:foo] $ ls
package-lock.json package.json

And I then install:

[user@host:foo] $ npm install
added 1 package in 341ms

1 package is looking for funding
  run `npm fund` for details
[user@host:foo] $ ls node_modules/@swc/
core

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:

1. npm is generating an inconsistent package-lock.json when node_modules has your platform-specific dependency installed.
2. When installing from this inconsistent package-lock.json, npm fails to try to correct the problem by comparing the optional dependencies to what's listed upstream

Expected Behavior

1. npm should preserve the full set of platform-specific optional deps for a package like @swc when rebuilding package-lock.json from an existing node_modules tree
2. npm install should warn if the package-lock.json becomes inconsistent because of the first case

Steps To Reproduce

See above.

Environment

• npm: 8.8.0
• Node.js:
• OS Name: OSX
• System Model Name: Macbook Pro

[user@host:foo] $ npm -v
8.8.0
[user@host:foo] $ node -v
v16.14.2
[user@host:foo] $ uname -a
Darwin host.foo.com. 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_ARM64_T8101 arm64

[user@host] $ npm config ls
; "user" config from /Users/user/.npmrc
; node bin location = /Users/user/.nvm/versions/node/v16.14.2/bin/node
; node version = v16.14.2
; npm local prefix = /Users/user/Development/foo
; npm version = 8.8.0
; cwd = /Users/user/Development/foo
; HOME = /Users/user
; Run `npm config ls -l` to show all defaults.

[juliusiqbal]

I had to use below code in package.json file and remove node_modules folder and run npm install.

"overrides": {
    "vite": {
      "rollup": "npm:@rollup/wasm-node"
    }
  }

I had to run below commands for dockerized app where npm i should run inside container.

docker compose run reusebin-ui npm i && \
  docker compose down && \
  rm -rf node_modules && \
  docker compose up --build

[d-luitwieler-anva]

I think we're running into the same problem being mentioned in this issue, but I'm currently running npm 9.8.1... Can somebody confirm if the same bug still exists on that npm version, so I can stop searching for the cause?

[d-luitwieler-anva]

I think we're running into the same problem being mentioned in this issue, but I'm currently running npm 9.8.1... Can somebody confirm if the same bug still exists on that npm version, so I can stop searching for the cause?

Finally figured out how it works and I can confirm that this problem still occurs on "npm 9.8.1"

[dkbhadeshiya]

I have tried this and faced the same issue on npm version 10.5.0 as well.

[ScarellaDev]

Ran into this issue with npm 10.2.3:

Error: Cannot find module '@nx/nx-linux-x64-gnu'

I had to add them to my optionalDependencies in my package.json in order for npm to add them to the package-lock.json:

"optionalDependencies": {
    "@nx/nx-darwin-arm64": "18.0.5",
    "@nx/nx-darwin-x64": "18.0.5",
    "@nx/nx-linux-x64-gnu": "18.0.5",
    "@nx/nx-win32-x64-msvc": "18.0.5"
  }

[andrecasal]

Ran into this issue today with npm 10.2.4.

In my case it was related to @rollup/rollup-darwin-x64.

Adding it tooptionalDependencies did not work.

"optionalDependencies": {
    "@rollup/rollup-darwin-x64": "4.14.2"
},

[driesvints]

I no longer experience this with the latest 4.14.3 release of @rollup/rollup-darwin-x64. I removed @rollup/rollup-darwin-x64 from optionalDependencies and can now install packages just fine again.

[dudasaus]

Can confirm adding to optionalDependencies worked to fix error that was occurring in GitHub Actions but not locally.

  "optionalDependencies": {
    "@rollup/rollup-linux-x64-gnu": "^4.14.3"
  }

Error:

Error: Cannot find module @rollup/rollup-linux-x64-gnu. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.

[ozknemoy]

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

[JamesCatt]

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.

[Austin-rgb]

I'm also experiencing a problem related to when using angular/cli $ng serve --open Node.js version v21.6.2 detected. Odd numbered Node.js versions will not enter LTS status and should not be used for production. For more information, please see https://nodejs.org/en/about/previous-releases/. An unhandled exception occurred: Cannot find module @rollup/rollup-android-arm64. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please trynpm i` again after removing both package-lock.json and node_modules directory. See "/tmp/ng-qujNWE/angular-errors.log" for further details. node:internal/process/promises:289 triggerUncaughtException(err, true / fromPromise /); ^

Error: Cannot find module @rollup/rollup-android-arm64. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try npm i again after removing both package-lock.json and node_modules directory. at requireWithFriendlyError (/home/ostiness/Desktop/project1/front/front/node_modules/rollup/dist/native.js:59:9) at Object. (/home/ostiness/Desktop/project1/front/front/node_modules/rollup/dist/native.js:68:76) ... 2 lines matching cause stack trace ... at Module.load (node:internal/modules/cjs/loader:1212:32) at Module._load (node:internal/modules/cjs/loader:1028:12) at cjsLoader (node:internal/modules/esm/translators:359:17) at ModuleWrap. (node:internal/modules/esm/translators:308:7) at ModuleJob.run (node:internal/modules/esm/module_job:218:25) at async ModuleLoader.import (node:internal/modules/esm/loader:323:24) { [cause]: Error: dlopen failed: library "/home/ostiness/Desktop/project1/front/front/node_modules/@rollup/rollup-android-arm64/rollup.android-arm64.node" needed or dlopened by "/data/data/com.termux/files/usr/bin/node" is not accessible for the namespace "(default)" at Module._extensions..node (node:internal/modules/cjs/loader:1475:18) at Module.load (node:internal/modules/cjs/loader:1212:32) at Module._load (node:internal/modules/cjs/loader:1028:12) at Module.require (node:internal/modules/cjs/loader:1237:19) at require (node:internal/modules/helpers:176:18) at requireWithFriendlyError (/home/ostiness/Desktop/project1/front/front/node_modules/rollup/dist/native.js:41:10) at Object. (/home/ostiness/Desktop/project1/front/front/node_modules/rollup/dist/native.js:68:76) at Module._compile (node:internal/modules/cjs/loader:1378:14) at Module._extensions..js (node:internal/modules/cjs/loader:1437:10) at Module.load (node:internal/modules/cjs/loader:1212:32) { code: 'ERR_DLOPEN_FAILED' } }

Node.js v21.6.2`

Deleting package-lock.json and node_modules and then running npm i never fixed the problem

[kishor82]

Deleting the lock file and node_modules directory, and then running npm i, worked for me 🚀 Node.js v20.9.0

[mctrafik]

Deleting the lock file and node_modules directory, and then running npm i, worked for me 🚀 Node.js v20.9.0

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.

[localpcguy]

@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.

[kishor82]

@mctrafik Well, it's not the complete solution, but not all of us encounter issues with regenerating the lockfile.

[ljharb]

@localpcguy very well said.

https://github.com/npm/cli/issues/4828#issuecomment-2077092392 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.

[hakaba]

@localpcguy in a CI and a industrialization process, this is not an option.

[schjetne]

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.

[D3press3dd]

I did this https://github.com/npm/cli/issues/4828#issuecomment-2077092392 and it worked me

[chrisfosterelli]

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.

[Azbesciak]

Since we have 2nd anniversary, is there any progress on that issue?

[isebbo]

Are there any progress to be seen?

[IRoye]

Are there any progress to be seen ? i just encountered this problem，the tip in the console Please trynpm iagain after removing both package-lock.json and node_modules directory dosent work for me

[fshengw]

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

[user@host:foo] $ npm -v
8.8.0
[user@host:foo] $ node
Welcome to Node.js v16.14.2.
Type ".help" for more information.
> process.arch
'arm64'

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 the package-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 directory npm generates a package-lock.json with all of the optional dependencies for @swc/core listed:

[user@host:foo] $ npm install @swc/core
[user@host:foo] $ grep 'node_modules/@swc/core-*' package-lock.json
    "node_modules/@swc/core": {
    "node_modules/@swc/core-android-arm-eabi": {
    "node_modules/@swc/core-android-arm64": {
    "node_modules/@swc/core-darwin-arm64": {
    "node_modules/@swc/core-darwin-x64": {
    "node_modules/@swc/core-freebsd-x64": {
    "node_modules/@swc/core-linux-arm-gnueabihf": {
    "node_modules/@swc/core-linux-arm64-gnu": {
    "node_modules/@swc/core-linux-arm64-musl": {
    "node_modules/@swc/core-linux-x64-gnu": {
    "node_modules/@swc/core-linux-x64-musl": {
    "node_modules/@swc/core-win32-arm64-msvc": {
    "node_modules/@swc/core-win32-ia32-msvc": {
    "node_modules/@swc/core-win32-x64-msvc": {

And it only installs the platform specific package:

[user@host:foo] $ ls -l node_modules/@swc/
total 0
drwxr-xr-x  22 user  staff  704 Apr 29 15:39 core
drwxr-xr-x   6 user  staff  192 Apr 29 15:39 core-darwin-arm64

If I then remove my package-lock.json, leave my node_modules directory as-is, and then reinstall, I get:

[user@host:foo] $ rm -rf package-lock.json
[user@host:foo] $ npm install
[user@host:foo] $ grep 'node_modules/@swc/core-*' package-lock.json
    "node_modules/@swc/core": {
    "node_modules/@swc/core-darwin-arm64": {

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 AND package-lock.json, and then re-run npm 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):

[user@host:foo] $ node
Welcome to Node.js v16.14.2.
Type ".help" for more information.
> process.arch
'arm64'
>
[user@host:foo] $ grep 'node_modules/@swc/core-*' package-lock.json
    "node_modules/@swc/core": {
    "node_modules/@swc/core-darwin-x64": {
[user@host:foo] $ ls
package-lock.json package.json

And I then install:

[user@host:foo] $ npm install
added 1 package in 341ms

1 package is looking for funding
  run `npm fund` for details
[user@host:foo] $ ls node_modules/@swc/
core

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:

1. npm is generating an inconsistent package-lock.json when node_modules has your platform-specific dependency installed.
2. When installing from this inconsistent package-lock.json, npm fails to try to correct the problem by comparing the optional dependencies to what's listed upstream

Expected Behavior

1. npm should preserve the full set of platform-specific optional deps for a package like @swc when rebuilding package-lock.json from an existing node_modules tree
2. npm install should warn if the package-lock.json becomes inconsistent because of the first case

Steps To Reproduce

See above.

Environment

• npm: 8.8.0
• Node.js:
• OS Name: OSX
• System Model Name: Macbook Pro

[user@host:foo] $ npm -v
8.8.0
[user@host:foo] $ node -v
v16.14.2
[user@host:foo] $ uname -a
Darwin host.foo.com. 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_ARM64_T8101 arm64

[user@host] $ npm config ls
; "user" config from /Users/user/.npmrc
; node bin location = /Users/user/.nvm/versions/node/v16.14.2/bin/node
; node version = v16.14.2
; npm local prefix = /Users/user/Development/foo
; npm version = 8.8.0
; cwd = /Users/user/Development/foo
; HOME = /Users/user
; Run `npm config ls -l` to show all defaults.

[yunyizea]

My computer is a Surface based on Windows ARM architecture, and I also encountered the same problem. I have tried to delete package-lock.json and node_modules, and then re-executed the npm install command, but the result has not changed. The following are my relevant error reports:

PS C:\Users\Yunyize\Documents\Projects\vite-project> npm i

added 110 packages, and audited 111 packages in 1m

16 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
PS C:\Users\Yunyize\Documents\Projects\vite-project> npm run dev

> vite-project@0.0.0 dev
> vite

C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\rollup\dist\native.js:59
                throw new Error(
                      ^

Error: Cannot find module @rollup/rollup-win32-arm64-msvc. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.
    at requireWithFriendlyError (C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\rollup\dist\native.js:59:9)
    at Object.<anonymous> (C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\rollup\dist\native.js:68:76)
    ... 2 lines matching cause stack trace ...
    at Module.load (node:internal/modules/cjs/loader:1208:32)
    at Module._load (node:internal/modules/cjs/loader:1024:12)
    at cjsLoader (node:internal/modules/esm/translators:348:17)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:297:7)
    at ModuleJob.run (node:internal/modules/esm/module_job:222:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:316:24) {
  [cause]: Error: \\?\C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\@rollup\rollup-win32-arm64-msvc\rollup.win32-arm64-msvc.node is not a valid Win32 application.
  \\?\C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\@rollup\rollup-win32-arm64-msvc\rollup.win32-arm64-msvc.node
      at Module._extensions..node (node:internal/modules/cjs/loader:1454:18)
      at Module.load (node:internal/modules/cjs/loader:1208:32)
      at Module._load (node:internal/modules/cjs/loader:1024:12)
      at Module.require (node:internal/modules/cjs/loader:1233:19)
      at require (node:internal/modules/helpers:179:18)
      at requireWithFriendlyError (C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\rollup\dist\native.js:41:10)
      at Object.<anonymous> (C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\rollup\dist\native.js:68:76)
      at Module._compile (node:internal/modules/cjs/loader:1358:14)
      at Module._extensions..js (node:internal/modules/cjs/loader:1416:10)
      at Module.load (node:internal/modules/cjs/loader:1208:32) {
    code: 'ERR_DLOPEN_FAILED'
  }
}

Node.js v20.13.1
PS C:\Users\Yunyize\Documents\Projects\vite-project> 

[yunyizea]

My computer is a Surface based on Windows ARM architecture, and I also encountered the same problem. I have tried to delete package-lock.json and node_modules, and then re-executed the npm install command, but the result has not changed. The following are my relevant error reports:我的电脑是基于Windows ARM架构的Surface，我也遇到了同样的问题。我尝试过删除package-lock.json和node_modules，然后重新执行npm install命令，但结果没有改变。以下是我的相关错误报告：

PS C:\Users\Yunyize\Documents\Projects\vite-project> npm i

added 110 packages, and audited 111 packages in 1m

16 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
PS C:\Users\Yunyize\Documents\Projects\vite-project> npm run dev

> vite-project@0.0.0 dev
> vite

C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\rollup\dist\native.js:59
                throw new Error(
                      ^

Error: Cannot find module @rollup/rollup-win32-arm64-msvc. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.
    at requireWithFriendlyError (C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\rollup\dist\native.js:59:9)
    at Object.<anonymous> (C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\rollup\dist\native.js:68:76)
    ... 2 lines matching cause stack trace ...
    at Module.load (node:internal/modules/cjs/loader:1208:32)
    at Module._load (node:internal/modules/cjs/loader:1024:12)
    at cjsLoader (node:internal/modules/esm/translators:348:17)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:297:7)
    at ModuleJob.run (node:internal/modules/esm/module_job:222:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:316:24) {
  [cause]: Error: \\?\C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\@rollup\rollup-win32-arm64-msvc\rollup.win32-arm64-msvc.node is not a valid Win32 application.
  \\?\C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\@rollup\rollup-win32-arm64-msvc\rollup.win32-arm64-msvc.node
      at Module._extensions..node (node:internal/modules/cjs/loader:1454:18)
      at Module.load (node:internal/modules/cjs/loader:1208:32)
      at Module._load (node:internal/modules/cjs/loader:1024:12)
      at Module.require (node:internal/modules/cjs/loader:1233:19)
      at require (node:internal/modules/helpers:179:18)
      at requireWithFriendlyError (C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\rollup\dist\native.js:41:10)
      at Object.<anonymous> (C:\Users\Yunyize\Documents\Projects\vite-project\node_modules\rollup\dist\native.js:68:76)
      at Module._compile (node:internal/modules/cjs/loader:1358:14)
      at Module._extensions..js (node:internal/modules/cjs/loader:1416:10)
      at Module.load (node:internal/modules/cjs/loader:1208:32) {
    code: 'ERR_DLOPEN_FAILED'
  }
}

Node.js v20.13.1
PS C:\Users\Yunyize\Documents\Projects\vite-project> 

And I also tried to manually install the missing dependency @rollup/rollup-win32-arm64-msvc in the error message, but to no avail.

[shgysk8zer0]

I'd hate to do it, but I just encountered this issue after switching to Mac from Linux, and I can't think of anything to do except to add package-lock.json to .gitignore. I know it is a bad idea, but... It's the only thing I can think of to just be able to work on Mac and deploy on Linux (Netlify, in my case).

[Salman2301]

bump ( voice - Kendrick from like that song ) Works in mac mini but not m1 mac even tried same package-lock.json tried moving the node_modules from mini using scp reinstall different version 21.x and 22.x, yarn, bun. pnpm etc Nothing works related to svelte extension in vscode Wasted 4hrs

[DanaIv]

What worked for my team was for someone on a Mac to manually remove the Linux dependencies from package-lock.json, remove the node_modules directory and re-run npm install. This added the optional dependencies for all platforms to package-lock.json and fixed our issue.

[Vittorio-QA]

What worked for my team was for someone on a Mac to manually remove the Linux dependencies from package-lock.json, remove the node_modules directory and re-run npm install. This added the optional dependencies for all platforms to package-lock.json and fixed our issue.

Hi @DanaIv, thank you for sharing your solution did it fix it permanently?

[Sidneycarlinijr]

After trying all the suggested solutions without success we found a fix that worked for us:

Changing the repository source path. For example:

From: ./My Projects/project/test

To: ./myprojects/project/test

Then, re-clone the project into the new folder to avoid any cache issues.

Hope this helps!

[capote1789]

What worked for my team was for someone on a Mac to manually remove the Linux dependencies from package-lock.json, remove the node_modules directory and re-run npm install. This added the optional dependencies for all platforms to package-lock.json and fixed our issue.

This one fix it for me as well, thanks!

[schettgen]

What worked for my team was for someone on a Mac to manually remove the Linux dependencies from package-lock.json, remove the node_modules directory and re-run npm install. This added the optional dependencies for all platforms to package-lock.json and fixed our issue.

This one fix it for me as well, thanks!

Looks like a really dirty workaround since it's will completely unsecure the process which npm ci tries to secure

[carlos-monti]

Hi there I'm having this error happening on github directly when running github actions

[huehnerlady]

Any update on this? Seems to be an issue for quite a while now?

[fadrian06]

astro dev

C:\xampp\htdocs\midu\curso-astro-demo\node_modules.pnpm\rollup@4.18.1\node_modules\rollup\dist\native.js:59 throw new Error( ^

Error: Cannot find module @rollup/rollup-win32-x64-msvc. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try npm i again after removing both package-lock.json and node_modules directory. at requireWithFriendlyError (C:\xampp\htdocs\midu\curso-astro-demo\node_modules.pnpm\rollup@4.18.1\node_modules\rollup\dist\native.js:59:9) at Object. (C:\xampp\htdocs\midu\curso-astro-demo\node_modules.pnpm\rollup@4.18.1\node_modules\rollup\dist\native.js:68:76) ... 2 lines matching cause stack trace ... at Module.load (node:internal/modules/cjs/loader:1197:32) at Module._load (node:internal/modules/cjs/loader:1013:12) at ModuleWrap. (node:internal/modules/esm/translators:202:29) at ModuleJob.run (node:internal/modules/esm/module_job:195:25) at async ModuleLoader.import (node:internal/modules/esm/loader:336:24) at async runCommand (file:///C:/xampp/htdocs/midu/curso-astro-demo/node_modules/.pnpm/astro@4.0.9_typescript@5.5.3/node_modules/astro/dist/cli/index.js:104:22) { [cause]: Error: No se encontró el proceso especificado. \?\C:\xampp\htdocs\midu\curso-astro-demo\node_modules.pnpm\@rollup+rollup-win32-x64-msvc@4.18.1\node_modules\@rollup\rollup-win32-x64-msvc\rollup.win32-x64-msvc.node at Module._extensions..node (node:internal/modules/cjs/loader:1452:18) at Module.load (node:internal/modules/cjs/loader:1197:32) at Module._load (node:internal/modules/cjs/loader:1013:12) at Module.require (node:internal/modules/cjs/loader:1225:19) at require (node:internal/modules/helpers:177:18) at requireWithFriendlyError (C:\xampp\htdocs\midu\curso-astro-demo\node_modules.pnpm\rollup@4.18.1\node_modules\rollup\dist\native.js:41:10) at Object. (C:\xampp\htdocs\midu\curso-astro-demo\node_modules.pnpm\rollup@4.18.1\node_modules\rollup\dist\native.js:68:76) at Module._compile (node:internal/modules/cjs/loader:1356:14) at Module._extensions..js (node:internal/modules/cjs/loader:1414:10) at Module.load (node:internal/modules/cjs/loader:1197:32) { code: 'ERR_DLOPEN_FAILED' } }

Node.js v18.19.0  ELIFECYCLE  Command failed with exit code 1.

[Moe03]

+1 bump for rollup on my side as well

Error: Cannot find module @rollup/rollup-win32-x64-msvc. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.

[taimurshaikh]

bump

[lorand-horvath]

@fadrian06 @Moe03 The rollup 4.18.1 error is caused by something else AFAICT, see if this workaround fixes the problem https://github.com/rollup/rollup/issues/5571#issuecomment-2220490077 Is this on Windows 7?

[fadrian06]

yes, effectively I've Windows 7, with npm i rollup@4.18.0 -D -E I fixed the problem

[lorand-horvath]

yes, effectively I've Windows 7, with npm i rollup@4.18.0 -D -E I fixed the problem

Then you will have to use the older rollup@4.18.0 on every new project from now on. Replacing the native rust-compiled rollup with the wasm version, but still using the latest 4.18.1 is better IMHO.

[fadrian06]

Then you will have to use the older rollup@4.18.0 on every new project from now on. .

effectively, it's a little tedious to downgrade rollup version, but meanwhile they publish rollup 4.18.2 or something that works

[lorand-horvath]

meanwhile they publish rollup 4.18.2 or something that works

Nope, won't solve the issue because they're using an updated rust toolchain since rollup 4.18.1, which isn't compatible with win 7 anymore, and I don't believe they'll revert. It's exactly the same problem with swc used in next.js 14.2+. Of course it's your choice after all, I don't want to force anything on you.

[mohamed-badaoui]

Same issue

An unhandled exception occurred: Cannot find module @rollup/rollup-linux-x64-musl.
npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828).
Please try `npm i` again after removing both package-lock.json and node_modules directory.

Reinstalling didn't help

[lorand-horvath]

Same issue

An unhandled exception occurred: Cannot find module @rollup/rollup-linux-x64-musl.
Reinstalling didn't help

Have you tried this workaround? https://github.com/rollup/rollup/issues/5571#issuecomment-2220490077

[kryshac]

I noticed a bug, when package-lock.json is generated on linux, the optional dependencies that are only for linux are installed, but on windows all the optional dependencies are installed. And with the one generated on windows, it also works on linux and mac os.

[mohamed-badaoui]

Same issue

An unhandled exception occurred: Cannot find module @rollup/rollup-linux-x64-musl.
Reinstalling didn't help

Have you tried this workaround? rollup/rollup#5571 (comment)

It didn't work :/

I edited package.json and add :

  "overrides": {
    "vite": {
      "rollup": "npm:@rollup/wasm-node"
    }
  },

Then I did:

rm -rf node_modules
rm -f yarn.lock
yarn install

But still have the same error:

An unhandled exception occurred: Cannot find module @rollup/rollup-linux-x64-musl.
npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828).
Please try `npm i` again after removing both package-lock.json and node_modules directory

My config is:

yarn -v
4.3.0

npm -v
10.7.0

[mohamed-badaoui]

FYI, I only changed docker image and it works (same npm cli version) I was using Alpine image node:lts-alpine3.20 and change for node:lts-bookworm-slim

Do not know why it is not working with alpine images anymore.

[lorand-horvath]

@mohamed-badaoui For yarn, you have to use "resolutions" instead of "overrides" in package.json. Please keep in mind we are discussing npm/cli-related issues here.

[BriceShatzer]

hey this is still happening....has this ever been even been acknowledged?