supportedArchitectures: allow architecture tuples, not only a cartesian product

[meck93]

Contribution

• I'd be willing to implement this feature (contributing guide)

Describe the user story

We use a monorepo. I want pnpm to install the platform packages for the machines we really use. Today pnpm installs many packages that no machine can run.

Our repository has three targets:

• developers work on macOS arm64
• CI runs on Linux x64 with glibc
• one Docker image runs on Linux x64 with musl

That is three platforms. I cannot write three platforms. supportedArchitectures takes three separate lists, and pnpm installs the cartesian product:

supportedArchitectures:
  os: [darwin, linux]
  cpu: [x64, arm64]
  libc: [glibc, musl]

This is 2 x 2 x 2. pnpm installs eight combinations. We only use three.

I measured with pnpm 11.9.0 on Node 24.12.0.
The libc line adds 1.0 GB in 44 packages to every developer machine and every CI job.
461 MB of that, in 21 packages, is Linux arm64 musl which is a combination, we don't use.

The two largest are:

190M  @supabase/cli-linux-arm64-musl
119M  @next/swc-linux-arm64-musl

Describe the solution you'd like

Let supportedArchitectures also accept a list of tuples. Each tuple is one platform:

supportedArchitectures:
  - { os: darwin, cpu: arm64 }
  - { os: linux, cpu: x64, libc: glibc }
  - { os: linux, cpu: x64, libc: musl }

pnpm installs an optional dependency if it matches one tuple or more.

A missing key means "any value". { os: linux } matches all Linux packages. This could keep configurations short.

The current object form stays valid. pnpm can read it as one tuple that holds lists, so old configurations do not change behaviour.

Describe the drawbacks of your solution

• Somewhat two shapes for one setting. The documentation must explain both (list vs. tuplates). Users must choose?
• If a user gives a list and an object together, pnpm must reject it with a clear error or define a merge rule.

Describe alternatives you've considered

1. Declare the needed packages as direct optionalDependencies. This didn't work. pnpm applies the libc filter to optional dependencies even when a project declares them directly. On a glibc machine pnpm skips them. Our Docker build then failed, because the musl binaries were absent.
2. Per-package scoping, for example a setting that gives one architecture list to one package. I think this is worse. supportedArchitectures describes the machines that will run the install output. It does not describe single packages. Per-package rules also become unclear when two packages want different variants of the same dependency.
3. Accept the cost 😆

One more thing, I checked the existing issues first and found the following:

• pnpm install multiple bindings of different libc #7362 closed by fix: install packages with incompatible libc #8569
• pnpm downloads binaries for other platforms even with explicit supportedArchitectures #11702 closed by fix: infer missing platform fields of optional dependencies from the package name #12312

Both report that the filter is too weak. This request asks for the opposite, a filter that is more exact. I did not find an existing request for tuples. Please close this issue if one exists.