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

JustinChristensen · 2022-04-29T21:48:11Z

Is there an existing issue for this?

I have searched the existing issues

This issue exists in the latest npm version

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:

npm is generating an inconsistent package-lock.json when node_modules has your platform-specific dependency installed.
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

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

The text was updated successfully, but these errors were encountered:

JustinChristensen · 2022-05-11T01:49:52Z

@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 · 2022-05-19T00:55:28Z

Bump

RobbieClarken · 2022-06-03T07:41:35Z

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 · 2022-06-22T15:30:40Z

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 · 2022-06-28T01:46:33Z

bump

nikkhn · 2022-07-12T19:22:45Z

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

sgoodluck · 2022-08-09T00:36:58Z

bump

alcuadrado · 2022-09-16T13:32:32Z

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 · 2022-10-04T03:29:01Z

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 · 2022-10-12T12:52:33Z

bump

douglassllc · 2022-12-01T11:27:26Z

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?

HeadCookie · 2025-03-20T21:27:18Z

Experienced the same issue on a feature branch. What solved it for me was removing package-lock.json and node_modules, checking out package-lock.json from a working master branch and then run npm i.

mctrafik · 2025-03-20T21:59:03Z

Sorry for another reply, but the CONFIRMED WORKAROUND is now hidden in the sea of spam:

You can fix this behavior PERMANENTLY by copying optionalDependencies from the package into your package.json

I.e. if you binaries for biome,bun and swc to be in the package-lock and not disappear:

{
 "optionalDependencies": {
    "@biomejs/cli-darwin-arm64": "^1.9.2",
    ...
    "@biomejs/cli-win32-x64": "^1.9.2",
    "@oven/bun-darwin-aarch64": "^1.1.43",
    ...
    "@oven/bun-windows-x64-baseline": "^1.1.43",
    "@swc/core-darwin-arm64": "^1.10.17",
    ...
    "@swc/core-win32-x64-msvc": "^1.10.17"
  },

Why other solutions don't work

npm i after deleting node_modules or clearning cache
DOES NOT WORK because the next time someone other than you on a different architecture, they will mess up package-lock.json for you again
Using pnpm, bun or w/e. DOES NOT WORK because it's not npm, and this is an npm issue, and migrations aren't free because these tools aren't intercompatible
Resetting your package-lock.json DOES NOT WORK because you'll be breaking it for the next person who's not using the same arch as you.

How you can help

Ther's a good discussion on the solution here: #8127 so feel free to contribute.

… but keep them 'in the tree' Fixes: npm#4828 Fixes: npm#7961 Replaces: npm#8127 Replaces: npm#8077 When optional dependencies fail, we don't want to install them, for whatever reason. The way this "uninstallation" is done right now is by simply removing the dependencies from the ideal tree during reification. Unfortunately, this means that what gets saved to the "hidden lockfile" is the edited ideal tree as well, and when NPM runs next, it'll use that when regenerating the "real" package-lock. This PR tags failed optional deps such that they're still added to the "trash list" (and thus have their directories cleaned up by the reifier), but prevents Arborist from removing them altogether from the ideal tree (which is usually done by setting their parent to `null`, making them unreachable, and letting them get GC'd).

zkat · 2025-03-22T18:58:36Z

#8177

I made some progress with this. Should be good to go next week when I’m back in the office.

… but keep them 'in the tree' Fixes: npm#4828 Fixes: npm#7961 Replaces: npm#8127 Replaces: npm#8077 When optional dependencies fail, we don't want to install them, for whatever reason. The way this "uninstallation" is done right now is by simply removing the dependencies from the ideal tree during reification. Unfortunately, this means that what gets saved to the "hidden lockfile" is the edited ideal tree as well, and when NPM runs next, it'll use that when regenerating the "real" package-lock. This PR tags failed optional deps such that they're still added to the "trash list" (and thus have their directories cleaned up by the reifier), but prevents Arborist from removing them altogether from the ideal tree (which is usually done by setting their parent to `null`, making them unreachable, and letting them get GC'd).

- `package-lock.json` is missing @rollup/rollup-darwin-arm64. - See npm/cli#4828.

uchkunrakhimow · 2025-03-25T19:06:16Z

# Install architecture-specific Rollup module for ARM64 | AMD64
RUN if [ "$(uname -m)" = "aarch64" ]; then \
      npm install @rollup/rollup-linux-arm64-musl --no-save; \
    elif [ "$(uname -m)" = "x86_64" ]; then \
      npm install @rollup/rollup-linux-x64-musl --no-save; \
    fi

… but keep them 'in the tree' Fixes: npm#4828 Fixes: npm#7961 Replaces: npm#8127 Replaces: npm#8077 When optional dependencies fail, we don't want to install them, for whatever reason. The way this "uninstallation" is done right now is by simply removing the dependencies from the ideal tree during reification. Unfortunately, this means that what gets saved to the "hidden lockfile" is the edited ideal tree as well, and when NPM runs next, it'll use that when regenerating the "real" package-lock. This PR tags failed optional deps such that they're still added to the "trash list" (and thus have their directories cleaned up by the reifier), but prevents Arborist from removing them altogether from the ideal tree (which is usually done by setting their parent to `null`, making them unreachable, and letting them get GC'd).

broomfn · 2025-03-27T09:42:02Z

Install architecture-specific Rollup module for ARM64 | AMD64

RUN if [ "$(uname -m)" = "aarch64" ]; then
npm install @rollup/rollup-linux-arm64-musl --no-save;
elif [ "$(uname -m)" = "x86_64" ]; then
npm install @rollup/rollup-linux-x64-musl --no-save;
fi

Yes, nice workaround 🏆

… but keep them 'in the tree' Fixes: #4828 Fixes: #7961 Replaces: #8127 Replaces: #8077 When optional dependencies fail, we don't want to install them, for whatever reason. The way this "uninstallation" is done right now is by simply removing the dependencies from the ideal tree during reification. Unfortunately, this means that what gets saved to the "hidden lockfile" is the edited ideal tree as well, and when NPM runs next, it'll use that when regenerating the "real" package-lock. This PR tags failed optional deps such that they're still added to the "trash list" (and thus have their directories cleaned up by the reifier), but prevents Arborist from removing them altogether from the ideal tree (which is usually done by setting their parent to `null`, making them unreachable, and letting them get GC'd).

see fix implemented here, discussed at: npm/cli#4828 (comment) soon there will be a PR to address so we may be able to remove these optional dependencies once this PR is merged: npm/cli#8177

kashifshamaz21 · 2025-03-28T02:26:57Z

#8177

I made some progress with this. Should be good to go next week when I’m back in the office.

@zkat Thanks for the update on this issue.. Will the fix be ported back to npm v10.7.0 or only available on newer npm versions?

Fixed by removing package-lock.json and node_modules, then running npm i. see: npm/cli#4828

The publish action has failed because of npm/cli#4828

… but keep them 'in the tree' Fixes: #4828 Fixes: #7961 Replaces: #8127 Replaces: #8077 When optional dependencies fail, we don't want to install them, for whatever reason. The way this "uninstallation" is done right now is by simply removing the dependencies from the ideal tree during reification. Unfortunately, this means that what gets saved to the "hidden lockfile" is the edited ideal tree as well, and when NPM runs next, it'll use that when regenerating the "real" package-lock. This PR tags failed optional deps such that they're still added to the "trash list" (and thus have their directories cleaned up by the reifier), but prevents Arborist from removing them altogether from the ideal tree (which is usually done by setting their parent to `null`, making them unreachable, and letting them get GC'd).

- recreate package-lock file - see: npm/cli#4828

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

@zkat

…8184) … but keep them 'in the tree' This PR was authored by @zkat Fixes: #4828 Fixes: #7961 Replaces: #8127 Replaces: #8077 When optional dependencies fail, we don't want to install them, for whatever reason. The way this "uninstallation" is done right now is by simply removing the dependencies from the ideal tree during reification. Unfortunately, this means that what gets saved to the "hidden lockfile" is the edited ideal tree as well, and when npm runs next, it'll use that when regenerating the "real" package-lock. This PR tags failed optional deps such that they're still added to the "trash list" (and thus have their directories cleaned up by the reifier), but prevents Arborist from removing them altogether from the ideal tree (which is usually done by setting their parent to `null`, making them unreachable, and letting them get GC'd). PS: It's Friday, this is what I managed to get done together. I'm making this a draft PR for now so folks can look at it, but I want to make sure both reifiers work well, fix some messaging issues, and clean stuff up (I'm pretty sure I'm guarding `ideallyInert` in more places than I need to, because I was trying to find the right spot). Still, feel free to talk about the approach. I'll get back to this on Monday. PPS: also hi Co-authored-by: Kat Marchán <kzm@zkat.tech>

JustinChristensen added Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release labels Apr 29, 2022

jlarmstrongiv mentioned this issue Jun 4, 2022

Cross-platform package-lock.json vercel/turborepo#1335

Closed

andychow326 mentioned this issue Jun 10, 2022

Switch to graphql-codegen authgear/authgear-server#2081

Merged

Brooooooklyn mentioned this issue Aug 9, 2022

Fix reinstall from cache cause optionalDependencies being deleted from package-lock.json #5282

Closed

Brooooooklyn mentioned this issue Aug 30, 2022

Error: Cannot find module '@napi-rs/snappy-linux-x64-gnu' - on M1 Mac Brooooooklyn/snappy#84

Closed

ntkme mentioned this issue Sep 2, 2022

The new update does not contains Dart Sass embedded sass/embedded-host-node#163

Closed

jfsoul mentioned this issue Sep 12, 2022

chore: Trigger snyk guardian/prosemirror-typerighter#223

Merged

Brooooooklyn mentioned this issue Sep 13, 2022

Cannot find module '@node-rs/xxhash-linux-x64-gnu' swc-project/swc-node#668

Closed

alcuadrado mentioned this issue Sep 16, 2022

Platform-specific packages strategy and lockfiles napi-rs/napi-rs#1316

Closed

jfsoul added a commit to guardian/prosemirror-typerighter that referenced this issue Sep 26, 2022

fix: regenerate lockfile due to npm/cli#4828

a0d4f39

Chen-jj mentioned this issue Oct 19, 2022

@tarojs/cli创建和启动项目报错 NervJS/taro#12676

Closed

alcuadrado mentioned this issue Oct 31, 2022

Some corrupted lockfile NomicFoundation/hardhat-vscode#272

Closed

Brooooooklyn mentioned this issue Nov 2, 2022

Error: ERR_DLOPEN_FAILED Brooooooklyn/canvas#578

Closed

aeneasr mentioned this issue Nov 4, 2022

Version releases break npm ci in dependents ory/elements#47

Closed

6 tasks

jteppinette mentioned this issue Nov 10, 2022

Could not resolve lightningcss.linux-arm64-gnu.node in Docker with M1 parcel-bundler/lightningcss#335

Closed

erikjohnson06 mentioned this issue Mar 20, 2025

Issues shelbybagwell/Natural-Disaster-Risk-Visualization-Mapping-Tool#41

Merged

szymon-halik mentioned this issue Mar 21, 2025

SGD delta generation does not generates a package.xml hardisgroupcom/sfdx-hardis#1130

Closed

zkat mentioned this issue Mar 22, 2025

fix(arborist): omit failed optional dependencies from installed deps,… #8177

Closed

thammerl added a commit to thammerl/speech-recognition that referenced this issue Mar 24, 2025

Try to fix CI build

4850886

- `package-lock.json` is missing @rollup/rollup-darwin-arm64. - See npm/cli#4828.

thammerl mentioned this issue Mar 24, 2025

Upgrade CI build to Java 21 and fix code formatting gabekole/speech-recognition#1

Merged

nick1udwig mentioned this issue Mar 27, 2025

make ui compile properly cross-platform again hyperware-ai/hyperdrive#721

Merged

sschaeffner added a commit to sschaeffner/fabxtest that referenced this issue Mar 28, 2025

fe-svelte: fix package-lock.json

9bda965

Fixed by removing package-lock.json and node_modules, then running npm i. see: npm/cli#4828

sschaeffner added a commit to sschaeffner/fabxtest that referenced this issue Mar 28, 2025

fe-svelte: fix package-lock.json

2d67335

Fixed by removing package-lock.json and node_modules, then running npm i. see: npm/cli#4828

wraithgar mentioned this issue Mar 31, 2025

fix(arborist): omit failed optional dependencies from installed deps #8184

Merged

kamtugeza added a commit to kamtugeza/rechainify that referenced this issue Mar 31, 2025

fix: platform-specific dependencies

552f473

The publish action has failed because of npm/cli#4828

manuelpuchta added a commit to digitalservicebund/a2j-kommunikationsplattform that referenced this issue Apr 2, 2025

Try to fix npm/cli issue

056063e

- recreate package-lock file - see: npm/cli#4828

manuelpuchta added a commit to digitalservicebund/a2j-kommunikationsplattform that referenced this issue Apr 2, 2025

Try to fix npm/cli issue

778007a

- recreate package-lock file - see: npm/cli#4828

b0ink mentioned this issue Apr 2, 2025

fix: support building on windows for 9.x and 8.0.x doubtfire-lms/doubtfire-web#922

Merged

13 tasks

owlstronaut closed this as completed in #8184 Apr 3, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

JustinChristensen commented Apr 29, 2022 •

edited

Loading

JustinChristensen commented May 11, 2022

JustinChristensen commented May 19, 2022

RobbieClarken commented Jun 3, 2022

pete55104 commented Jun 22, 2022

johnculviner commented Jun 28, 2022

nikkhn commented Jul 12, 2022

sgoodluck commented Aug 9, 2022

alcuadrado commented Sep 16, 2022

AboldUSER commented Oct 4, 2022

eliotSmithNYC commented Oct 12, 2022

douglassllc commented Dec 1, 2022

HeadCookie commented Mar 20, 2025 •

edited

Loading

mctrafik commented Mar 20, 2025

zkat commented Mar 22, 2025

uchkunrakhimow commented Mar 25, 2025

broomfn commented Mar 27, 2025

Install architecture-specific Rollup module for ARM64 | AMD64

kashifshamaz21 commented Mar 28, 2025

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

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

Comments

JustinChristensen commented Apr 29, 2022 • edited Loading

Is there an existing issue for this?

This issue exists in the latest npm version

Current Behavior

Expected Behavior

Steps To Reproduce

Environment

JustinChristensen commented May 11, 2022

JustinChristensen commented May 19, 2022

RobbieClarken commented Jun 3, 2022

pete55104 commented Jun 22, 2022

johnculviner commented Jun 28, 2022

nikkhn commented Jul 12, 2022

sgoodluck commented Aug 9, 2022

alcuadrado commented Sep 16, 2022

AboldUSER commented Oct 4, 2022

eliotSmithNYC commented Oct 12, 2022

douglassllc commented Dec 1, 2022

HeadCookie commented Mar 20, 2025 • edited Loading

mctrafik commented Mar 20, 2025

Why other solutions don't work

How you can help

zkat commented Mar 22, 2025

uchkunrakhimow commented Mar 25, 2025

broomfn commented Mar 27, 2025

Install architecture-specific Rollup module for ARM64 | AMD64

kashifshamaz21 commented Mar 28, 2025

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

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

JustinChristensen commented Apr 29, 2022 •

edited

Loading

HeadCookie commented Mar 20, 2025 •

edited

Loading