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

[JustinChristensen]

@nlf

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.

[JustinChristensen]

Bump

[RobbieClarken]

I'm also encountering this issue with a Next.js project:

• Deleting package-lock.json and running npm install on an M1 Mac results in a package-lock.json file that is no longer able to build the app on x86.
• This can be fixed by deleting package-lock.json and node_modules and re-running npm install.

Unfortunately developers often don't realise the package-lock.json file is broken because everything continues to run fine on their machine. It is only when the build runs in CI that we learn it is broken.

Here is a reproduction:

$ node --version
v16.13.0
$ npm --version
8.12.1
$ npx create-next-app@latest
What is your project named? … my-app
Creating a new Next.js app in /Users/robbie/demo/my-app.
$ cd my-app/
$ npm install

up to date, audited 223 packages in 480ms

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

found 0 vulnerabilities
$ git status
On branch main
nothing to commit, working tree clean
$ rm package-lock.json
$ npm install

up to date, audited 223 packages in 579ms

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

found 0 vulnerabilities
$ # ************ package-lock.json is now incompatible with x86 ************
$ git diff
diff --git a/package-lock.json b/package-lock.json
index cbbf946..a87c1e5 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -96,36 +96,6 @@
         "glob": "7.1.7"
       }
     },
-    "node_modules/@next/swc-android-arm-eabi": {
-      "version": "12.1.6",
-      "resolved": "https://registry.npmjs.org/@next/swc-android-arm-eabi/-/swc-android-arm-eabi-12.1.6.tgz",
-      "integrity": "sha512-BxBr3QAAAXWgk/K7EedvzxJr2dE014mghBSA9iOEAv0bMgF+MRq4PoASjuHi15M2zfowpcRG8XQhMFtxftCleQ==",
-      "cpu": [
-        "arm"
-      ],
-      "optional": true,
-      "os": [
-        "android"
-      ],
-      "engines": {
-        "node": ">= 10"
-      }
-    },
-    "node_modules/@next/swc-android-arm64": {
-      "version": "12.1.6",
-      "resolved": "https://registry.npmjs.org/@next/swc-android-arm64/-/swc-android-arm64-12.1.6.tgz",
-      "integrity": "sha512-EboEk3ROYY7U6WA2RrMt/cXXMokUTXXfnxe2+CU+DOahvbrO8QSWhlBl9I9ZbFzJx28AGB9Yo3oQHCvph/4Lew==",
-      "cpu": [
-        "arm64"
-      ],
-      "optional": true,
-      "os": [
-        "android"
-      ],
-      "engines": {
-        "node": ">= 10"
-      }
-    },
[...]
$ rm -r package-lock.json node_modules
$ npm install

added 222 packages, and audited 223 packages in 2s

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

found 0 vulnerabilities
$ # ************ package-lock.json is now ok again ************
$ git status
On branch main
nothing to commit, working tree clean

[pete55104]

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.

[johnculviner]

bump

[nikkhn]

bump - cannot get optional dependencies (namely @swc/core-linux-arm64-gnu) to install on my linux distro

[sgoodluck]

bump

[alcuadrado]

Confirming that this issue is still present. It's particularly important for projects using NAPI modules, as tons of them use platform-specific packages.

[AboldUSER]

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.

[eliotSmithNYC]

bump

[douglassllc]

I am having a similar issue. My project uses @ffmpeg-installer/ffmpeg. While using npm v6 all optional dependencies (arch specific) are installed. After my upgrade to npm v8 the optional dependencies no longer install. Per the npm documentation I attempted using --include=optional, but this did not resolve the issue.

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?

[ljharb]

@douglassllc following https://unpkg.com/browse/@ffmpeg-installer/[email protected]/package.json to eg https://unpkg.com/browse/@ffmpeg-installer/[email protected]/package.json, that package should only be installed when the "os" is darwin and the "cpu" is arm64. If you're on a machine that doesn't match those, it wouldn't be installed.

[douglassllc]

@ljharb thanks for the quick reply.

While using npm v6 I could run npm install --force and all archs for @ffmpeg-installer/ffmpeg would be installed. I know this was not the intention of this package, but it was nice that I could force another behavior. This is advantageous for my scenario as I am building an Electron app that supports multiple OSs / Archs. Once I upgraded to npm v8 the --force is no longer pulling down / installing all the available optional dependencies for this package. This means no way for me to build on Mac for Windows as the Windows ffmpeg executables are not being downloaded.

Reading the npm documentation, it seemed the --include=optional might allow me to forcefully pull down all the optional dependencies in @ffmpeg-installer/ffmpeg. However, this is not working I would expect.

I read through all the npm config options, but did not see anything other than --include which might allow for npm v8 to work similar to npm v6. Any recommendations or suggestions would be appreciated.

[woody-li]

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?

This issue also reproduced at v7.

[grusingh]

Does pnpm addresses this issue?

[stephanrotolante]

NPM Version 8.11.0

npm ci --omit=optional is still including pkgs that are not supported by my architecture even though I explicitly set the dependency and all versions of it as optional

[silverwind]

Also reproduces on [email protected].

[alcuadrado]

Commenting again here hoping to help the team prioritize this issue.

1. With the proliferation of NAPI-based native modules, in particular for development tools (e.g. esbuild), many projects are using platform-specific optional packages, either directly or as (transitive) dependencies.

2. This issue makes those projects very fragile, as deleting the lockfile and reinstalling is a common practice, and triggers this bug.

3. Moreover, the developer that does it won't notice any problem, until (hopefully) their cross-platform CI fails, or one of their teammates' workflow breaks.

[Ketcap]

Having this issue,

• it's breaking CI and I had to force it without "package-lock" which is not nice workaround. npm i --package-lock=false fixes the issue on CI/CD not recommending tho. My issue is related to using "turbo" while installing dependencies on M1 then pushing package and lock to cloud which has this issue. Related to issue that is mentioned above https://github.com/vercel/turbo/issues/3328

[cdimino]

I was able to get past this by manually editing my package-lock.json file to include the extra platform dependencies from another project that wasn't broken.

[Naija-geek]

delete the node_modules rm -rf node_modules

delete the package-lock.json or yarn.lock rm -f package-lock.json rm -f yarn.lock

clean the npm cache npm cache clean --force

Install the dependencies npm install

[b12k]

This issue (maybe) is caused by regeneration of package-lock.json when node_modules are already present.

The rule of thumb:

⚠️ If you want to regenerate package-lock.json (for any reason) remove node_modules before running npm install.

This bug/feature is not reproducible when using Yarn/PNPM and respective yarn.lock/pnpm-lock.yaml lock files

Example:

# Initial step
npm init -y
npm i turbo
# 👌 package-lock.json is generated 

# Case A
rm -rf package-lock.json
npm i
# package-lock.json is regenerated taking `node_modules` into consideration
# SO
# ❌ Initial step package-lock.json != Case A package-lock.json

# Case B
rm -rf package-lock.json node_modules
npm i
# package-lock.json is regenerated using only package.json
# SO
# ✅ Initial step package-lock.json == Case B package-lock.json

[henryjjjjj]

delete the node_modules rm -rf node_modules

delete the package-lock.json or yarn.lock rm -f package-lock.json rm -f yarn.lock

clean the npm cache npm cache clean --force

Install the dependencies npm install

Thank you, cleaning the cache worked! Azure CI is now building again!

[sanjaymereddy]

https://github.com/nrwl/nx-console/issues/1808 I still have this issue. I get below errors on my windows machine when I installed the "Nx Console" extension. I verified that I'm using VS Code and node 64bit. As @devongovett mentioned, package manager fails to install the dependencies correctly

[localpcguy]

This issue (maybe) is caused by regeneration of package-lock.json when node_modules are already present.

This definitely seems to be the issue, particularly (in my case at least) with respect to optional packages. When I run npm install without any node_modules, it installs the appropriate version for my system/os, but the package-lock still references all of the optional packages. But if I regenerate the package-lock after node_modules exist, it will only reference the installed optional dependencies in the package-lock and removes any that weren't installed for my system/os combo.

This become a problem then on CI, where the system/os is different and so it needs a different one of the optional dependencies, but won't install it because it is no longer referenced at all in the package-lock json file. My expectation would be that while there might be slight version differences, the package-lock should not diverge in this manner due to the existence of node_modules during build.

There are a number of workarounds that work, but it can be a bit of a pain to manage this discrepancy. As the package-lock file is generated, I would also not expect I need to manually manage merge conflict resolution, but that I can just regenerate it as needed, but this issue means that doesn't always work properly.

[lmgeorge]

delete the node_modules rm -rf node_modules

delete the package-lock.json or yarn.lock rm -f package-lock.json rm -f yarn.lock

clean the npm cache npm cache clean --force

Install the dependencies npm install

For now, we've added this workaround as part of the project's package.json. It's not elegant, but it works.

{
  "scripts": {
    "prereinstall": "rm -rf ${npm_config_cache} ./package-lock.json ./npm-shrinkwrap.json ./node_modules",
    "reinstall": "npm_config_package_lock=true npm i",
    "postreinstall": "npm shrinkwrap" // optional
  }
}

[sametsahin1]

I'm getting the same error. After deleting 2 files and cleaning the cache, I uploaded it 20 more times, but I'm getting the same error.

[Diboby]

Did you try with ‘-f’ option ?

[sametsahin1]

Now I tried again with force and got the same error again.

[Diboby]

Add @rollup/rollup-win32-x64-msvc in your dev dependencies with 'npm i -f -D @rollup/rollup-win32-x64-msvc'