[BUG] OS specific module breaks workspace installation

[MondoGao]

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

When workspace config contains a package that requests an specific os/cpu, if current platform doesn't match that requirement, npm will panic and throw 'EBADPLATFORM' error.

Currently we can't mark a workspace package "optional" in any ways. In order to finish the installation process, we need to use "--force" flag.

Packages that need to build sub n-api platform-specific packages like esbuild face this issue.

Expected Behavior

Let npm have a config to consider a workspace package "optional".

One method to archive that is using optionalDependencies config:

# root pacage.json
{
  "workspaces": ["a"],
  "optionalDependencies": {
    "a": "*"
  }
}

Or add another config like the peerDependenciesMeta:

# root pacage.json
{
  "workspaces": ["a"],
  "workspacesMeta": {
    "a": {
      "optional": true
    }
  }
}

Steps To Reproduce

For example:

# root pacage.json
{
  "workspaces": ["a"]
}

# a/package.json
{
  "name": "a",
  "os": [
    "darwin"
  ],
  "cpu": [
    "x64"
  ]
}

When trying to run npm install on an different platform, error like below will be thrown:

Environment

• npm: 9.4.0
• Node.js: 16.18.1
• OS Name: MacOS 13.0.1
• System Model Name: Macbook Pro 16'
• npm config: unrelated

[MondoGao]

Related issue in yarn 1: yarnpkg/yarn#5951

[DevCon1100]

Access

[DevCon1100]

Access

[fritzy]

This isn't really a bug, so it probably be in the npm/rfcs repo, but it also feels like an oversight. We should probably do this.

[kasperisager]

I just hit this as well with a monorepo that contains OS and architecture specific packages. As a user of npm, it definitely feels like a bug and renders the workspace feature unusable for such monorepos.

[loozhengyuan]

Just encountered the same issue as well and it really does make the workspace rather unusable. It also feels quite hacky having to use --force to bypass this error.