[Bug]: Execution toolchain defined without `target_compatible_with` makes it a candidate to selection

[guw]

What happened?

rules_nodejs registers two toolchains:

rules_nodejs/nodejs/private/nodejs_toolchains_repo.bzl

Lines 110 to 121 in 356c5ff

	toolchain(
	name = "{platform}_toolchain",
	exec_compatible_with = {compatible_with},
	toolchain = "@{user_node_repository_name}_{platform}//:toolchain",
	toolchain_type = "@rules_nodejs//nodejs:toolchain_type",
	)
	toolchain(
	name = "{platform}_toolchain_target",
	target_compatible_with = {compatible_with},
	toolchain = "@{user_node_repository_name}_{platform}//:toolchain",
	toolchain_type = "@rules_nodejs//nodejs:toolchain_type",
	)

One is for execution on the host (execution toolchain) and another one for cross-compilation. However, the execution toolchain is defined without target_compatible_with, which makes it applicable to all possible targets (no constraints). In our situation this leads to an issue where NodeJS Linux AMD64 is picked wrongly instead of Linux ARM64 when building multi-platform containers on AMD64 machine.

This issue appeared after migrating to bzlmod. In our pre-bzlmod WORKSPACE setup we manually registered NodeJS toolchains ourselves and the problem does not occur.

Version

Development (host) and target OS/architectures:

• Host: Linux AMD64
• Target: Linux ARM64
• bzlmod

Output of bazel --version:

• 7.6.1

Version of rules_nodejs, or other relevant rules from your
WORKSPACE or MODULE.bazel file:

• 6.4.0

How to reproduce

• needs a multi-platform oci image build with transitions to produce arm64 image on amd64 host

Any other information?

Note, the second target specific toolchains was introduced in #3373. It seems to rely purely on lexicographic ordering. I do wonder if this is the correct approach and if both toolchain definitions are needed.

[fmeum]

Could you share more information about the situation in which the wrong node is chosen?

Generally speaking, if you build something that needs to include node in its runfiles (so that it can be run in a container image or as part of a test), you have to use the target toolchain (which only has a target constraint).

If you build something that runs node as part of a build action, you need the exec toolchain. Since running node in a build action doesn't "produce" something that's inherently tied to any particular OS/arch, it does make sense that the exec toolchain only has exec constraints and no target constraints.

[fmeum]

Forget what I said above, the two toolchains use the same toolchain type. That's just wrong - target and exec toolchain need different toolchain types. #3800 is the right approach.

[guw]

Could you share more information about the situation in which the wrong node is chosen?

A very simplified (abstract) version is this:

load("@aspect_bazel_lib//lib:transitions.bzl", "platform_transition_filegroup")

oci_image(
    name = "_temp.image",
    ...
)

for arch in platforms:
    platform_transition_filegroup(
        name = name + "." + arch,
        srcs = [":_temp.image"],
        ...
    )

[lucasteixeira-cb]

@guw did you find any workaround? I've found the same issue.

[lucasteixeira-cb]

I've found the workaround here: https://github.com/bazel-contrib/rules_nodejs/pull/3855/files and it does work. Thanks @guw!