[Bug]: pnpm lockfile parsed and translated when building unrelated targets

[martinbeck]

What happened?

When building any non-JS target, Bazel always passes by the root /BUILD.bazel file and its npm_link_all_packages macro call, which creates the virtual store. Hence, any changes to the pnpm-lock.yaml file, which happens quite often in the JS ecosystem, will trigger reparsing and translating the lockfile into Starlark files, even when the Bazel target to build does not have any relationship to JS (e.g., Golang only). This creates some friction and unnecessary waiting times.

Version

Development (host) and target OS/architectures:

Output of bazel --version: bazel 7.6.1

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: 3.0.1

Language(s) and/or frameworks involved:
Go, Python, TS/JS

How to reproduce

This can be demonstrated in the rules_js repository itself. At the root run:

bazel clean --expunge
bazel build //:buildifier


There is a small time where it shows the parsing and translation of the pnpm-lock.yaml file into Starlark dependencies although not needed for the build target. This is exacerbated if the pnpm-lock.yaml file is as large as 100k lines and the system maybe not the latest anymore.

Any other information?

@dzbarsky mentioned an inflight PR converting that macro to be symbolic, which might be a solution.