Skip to content

Conversation

guw
Copy link
Contributor

@guw guw commented Aug 21, 2025

According to discussions in #3854 having two toolchains of the same type for different things is troublesome. It's better to have separate runtime as well as compile toolchains.

This commit creates a new runtime_toolchain_type and registers toolchains without execution constraints for this type. Once merged, rules_ts can start consuming the new toolchain type in its js_binary rule to ensure the correct Node for the correct target environment is selected.

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

Fixes #3854
Work towards #3795

PR Checklist

Please check if your PR fulfills the following requirements:

  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature (please, look at the "Scope of the project" section in the README.md file)
  • Documentation content changes

Does this PR introduce a breaking change?

  • Yes
  • No

It tries to remain compatible and support existing consumers.

Other information

This is an alternative to #3800.

@aspect-workflows
Copy link

aspect-workflows bot commented Aug 21, 2025

Test

All tests were cache hits

1 test (100.0%) was fully cached saving 50ms.

@guw
Copy link
Contributor Author

guw commented Aug 23, 2025

This requires follow up fixes in rules_js to start consuming the new toolchain.

@guw guw force-pushed the add_runtime_toolchain branch from 2bdbe1f to 3a0c8a3 Compare August 23, 2025 06:18
@fmeum
Copy link
Member

fmeum commented Aug 23, 2025

I really like where this is going. I will review this in detail soon.

Copy link
Collaborator

@alexeagle alexeagle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why does this introduce a new zlib dependency? is that related to the toolchain type, or is it fixing some existing issue at HEAD?

@guw
Copy link
Contributor Author

guw commented Sep 26, 2025

I couldn't build the project successfully on my Mac without it (ran into bazelbuild/bazel#25124). Thus, the dependency is likely there but as a transitive. I agree that this might be too problematic.

Any recommendations @alexeagle?

guw added 3 commits October 21, 2025 10:24
According to discussions in bazel-contrib#3854 having two toolchains of the same type for different things is troublesome. It's better to have separate runtime as well as compile toolchains.

This commit creates a new runtime_toolchain_type and registers toolchains without execution constraints for this type. Once merged, rules_ts can start consuming the new toolchain type in its js_binary rule to ensure the correct Node for the correct target environment is selected.

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

Fixes bazel-contrib#3854
Work towards bazel-contrib#3795
@alexeagle alexeagle force-pushed the add_runtime_toolchain branch from 3a4fc5f to 72f5f23 Compare October 21, 2025 17:24
@alexeagle
Copy link
Collaborator

I'm going to remove zlib dep, if there's a problem it can be a separate PR

Copy link
Collaborator

@alexeagle alexeagle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool, thanks!

@alexeagle alexeagle merged commit 82738bd into bazel-contrib:main Oct 21, 2025
35 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

3 participants