[u9g]

Fixes #3040.

npm_translate_lock built each optional dependency's select() from its os and cpu alone, so on linux a package that ships glibc and musl builds linked both (for example @rollup/rollup-linux-x64-gnu and -musl, or @anthropic-ai/claude-agent-sdk-linux-x64 and -linux-x64-musl, about 235 MB each).

Changes

• pnpm.bzl reads libc from pnpm-lock.yaml packages, beside os and cpu.

• _collect_dep_constraints collects it, and it reaches npm_import_links_rule as a new internal deps_libcs attr, the same way deps_oss and deps_cpus do.

• _to_deps_attr puts dependencies that declare os, cpu and libc in their own select(). On linux they are keyed on new @aspect_rules_js//platforms/pnpm:linux_<cpu>_<libc> config settings over the existing //platforms/libc constraint. Other OSes keep <os>_<cpu>, since pnpm only checks libc on linux.

• Each such dependency is also keyed on linux_<cpu>_unconstrained. A platform that doesn't set //platforms/libc (its default is unconstrained) still links every variant, so nothing changes unless a platform asks for glibc or musl.

• docs/pnpm.md gets a short "Platform-specific packages" section showing how to set it.

• pnpm.to_bazel_constraints picks each dependency's select() group and conditions, which replaces the if/elif chain in _to_deps_attr. A dependency that declares libc without os or cpu is grouped with the libc dependencies too: a missing os or cpu allows all of them, as in pnpm, and aix folds into linux so that conditions never overlap.

• os, cpu and libc are normalized to lists when the lockfile is read, since package.json allows a string as well ("libc": "glibc" in sass-embedded).

Test plan

• New os_cpu_libc_constraints_test in pnpm_test.bzl; parse_pnpm_lock_tests expects the new libc field.
• New constraints_test, more cases in os_cpu_libc_constraints_test, and a parse test for scalar and list os/cpu/libc.
• examples/nextjs/snapshots/next_links_defs.bzl regenerated; //nextjs:write_next_links_defs_test passes on bazel 7.7.1.
• snapshots/rollup_links_defs.bzl regenerated: the linux_* entries move into the libc select().
• cquery on //:.aspect_rules_js/node_modules/rollup@4.55.2's direct deps, with a throwaway platform on the host:
  • no libc set: rollup-linux-x64-gnu and rollup-linux-x64-musl, as before
  • //platforms/libc:glibc: rollup-linux-x64-gnu only
  • //platforms/libc:musl: rollup-linux-x64-musl only
• bazel test //npm/... //platforms/...: the 125 tests that load pass. A few targets under the root package didn't load where I ran this, because it couldn't fetch the example packages that come from GitHub commit tarballs; none of them involve this change.
• buildifier (check + lint) and prettier 3.1.0 are clean on the changed files.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

[CLAassistant]

All committers have signed the CLA.

[jbedard]

Please fix the failing snapshot tests which will also provide a diff of the real results of this change helping the review process

[jbedard]

Do we need the same fix for windows? 😨

[u9g]

Not with the data we have. @rollup/rollup-win32-x64-gnu and -msvc both declare only os: [win32] and cpu: [x64] in the lockfile, with no libc or other field to tell them apart, so pnpm installs both on win32 x64 as well. Choosing one would need a mapping from package names to toolchains that pnpm doesn't have, so I've left windows as is.

[jbedard]

What if we have k in deps_cpus and k in deps_libcs but not k in deps_oss? Is that impossible and libc constraints only exist if os+cpu constraints also exist?

Either way it makes me wonder if this 3-if/else-block is no longer the ideal way to structure this code. I'm not sure if you have a better idea or if it's necessary at the time but please give it a thought...

[u9g]

Possible, yes: npm doesn't require os or cpu alongside libc, though every native package I've seen declares all three. Before this fix, such a dependency fell back to the os/cpu-only branch and the libc was dropped.

I replaced the if/elif chain with pnpm.to_bazel_constraints(oss, cpus, libcs), which returns the select() group and the conditions for one dependency. _to_deps_attr now just buckets dependencies by group. Any dependency that declares libc goes in the libc group. A missing os or cpu means all of them, as it does in pnpm, so cpu: [x64], libc: [musl] becomes darwin_x64, win32_x64, … plus linux_x64_{musl,unconstrained}. aix maps to the linux constraint, so it's folded into linux to keep the conditions within one select() from overlapping. Covered in constraints_test and os_cpu_libc_constraints_test. The rollup snapshot is unchanged by the refactor.

[jbedard]

The generated Next.js links snapshot also needs to be updated. The current CI failure shows examples/nextjs/snapshots/next_links_defs.bzl still expecting the old linux_<cpu> selects while the generated output now contains linux_<cpu>_{glibc,musl,unconstrained}:

https://github.com/aspect-build/rules_js/actions/runs/36410446225/job/109039252901

The failure suggests running:

bazel run //nextjs:write_next_links_defs

--codex

[jbedard]

libc needs normalization here because it is valid as either a string or a list. npm's documented example uses "libc": "glibc", and pnpm preserves that scalar form; this repo already has examples in e2e/pnpm_lockfiles/v101/pnpm-lock.yaml (and v110/v120). As written, a scalar flows into deps_libcs, which is later passed to attr.string_list_dict() (or would be iterated character-by-character by _resolve_pnpm_constraint_values), so valid projects such as ones using sass-embedded will fail repository evaluation. Could we normalize a scalar to [value] and add coverage for both forms?

--codex

[u9g]

Good catch, thanks. os, cpu and libc are now normalized to a list when the lockfile is read (_constraint_list in pnpm.bzl), so the scalar form used by sass-embedded in e2e/pnpm_lockfiles/v120 works. I did os and cpu too because package.json allows a string for them as well. The new parse test covers both the scalar and the list form.

[u9g]

Rebased on main. I regenerated examples/nextjs/snapshots/next_links_defs.bzl with bazel run //nextjs:write_next_links_defs, and the diff is what this change is meant to do: @next/swc-linux-*-gnu and -musl move from linux_<cpu> to linux_<cpu>_{glibc,musl,unconstrained}. //nextjs:write_next_links_defs_test passes locally on bazel 7.7.1, as does bazel test //npm/private/test:all //platforms/... (118 tests). The review fixes are in a separate commit, 0b6e263.