Simplify output flavor with starlark configuration

[ashi009]

🚀 feature request

Relevant Rules

ts_library and potentially other rules

Description

Currently, all the javascript rules use providers to differentiate outputs for different modes, eg. AMD, ESM. Consumers will then pick the right output based on their needs by using a provider or add a proxy filegroup to pick the right output_group.

However, this approach requires that the output files of different flavors be unique, and there is no simple way to create a target that consumes a dependency tree of specific flavor outputs. Consumers must know the right way to pick the output flavor they want.

Describe the solution you'd like

Use build settings API to transparently determine the output of a dependency ts_library. ts_library always produces the output with the same name, and the content may vary based on the build settings.

ts_library(
  # implicitly depends on the build settings for typescript, and it will 
  # produce only one set of outputs as `DefaultInfo` based on the
  # build settings, and bazel will create different output dirs for
  # different build configs -- consumers only see the output tree
  # matching their config.
  name = "lib",
)

devserver(
  # implicitly set the build settings for the deps with a transition:
  # [
  #   { “@npm//@bazel/typescript:mode”: "dev" },
  #   { “@npm//@bazel/typescript:target”: "es5" },
  #   { “@npm//@bazel/typescript:module”: "amd" },
  # ]
  deps = [":lib"],
)

rollup_bundle(
  # implicitly set the build settings for the deps with a transition:
  # [
  #   { “@npm//@bazel/typescript:mode”: "prod" },
  #   { “@npm//@bazel/typescript:target”: "esnext" },
  #   { “@npm//@bazel/typescript:module”: "esmodule" },
  # ]
  deps = [":lib"],
)

This could also enable possibilities like build nodejs/browser targets with the same dependency graph (eg. #2073).

See bazel doc and example from rules_go.

Describe alternatives you've considered

[DavidANeil]

This feels similar to the recent work to move some tsconfig into a starlark dict/rule, but using transitions instead.

Do you feel like transitions provide a certain advantage, or was it just top-of-mind?

[ashi009]

There should be lots of advantages over the current implementation.

• The current implementation generates a huge action graph for all flavors at once, and bazel has to analyze those actions all together, though some of them will never be used. With build settings, only one flavor will be analyzed at a time unless there is a transition to require a different flavor.
• The implementation should be significantly simpler, as the rule only need to deal with a single flavor at once (generate a single tsconfig as well), and the dependent rules will only see that flavor. So we don't need to work around those source locating difficulties and we don't need to understand all those providers to implement a rule. Everything should be as simple as DefaulInfo.
• With build settings we can build any flavor we want, not limited to the predefined list of flavors. Eg. ESnext build.
• Support target based select in build files.
• Build settings also provide a common ground for people to extend the frontend build system. For instance, add browserslist support as a build setting and css rules can take the hint from that config (this needs further discussion, but I think the idea should be the same).

[alexeagle]

How is this different from ts_project? It already generates only one action, has a tremendously simpler implementation, and you can use the out_dir attribute to get different output flavors to different distinct paths in the output tree.

[ashi009]

Well, I'd say completely different.

ts_project requires the user to write many tsconfig files for different outputs, which means, the consuming rule won't be able to choose the output they expect without modifying the provider rule -- thinking about the long-standing xx_proto_library issue in g3.

Also, if multiple outputs were required, users must add those actions as rules in build files -- which is tedious, error-prone, and doing things bazel is capable of doing (pretty much the definition of toil).

Most importantly, ts_project is not something one would use in a bazel idiomatic environment. The simplicity ts_project implies is due to its limited capability. I wish that the build settings API could reduce ts_library's necessary complexity, yet delivering the same or even better functionalities.

We can discuss more on slack -- if you have time.

[ashi009]

To clarify, the "output dir" is the top-level bazel output directory right under the bazel-out:

bazel-out/
  local_linux-fastbuild/        <== this will be different for different settings

[gregmagolan]

No longer in scope for rules_nodejs which only supplies the Node.js toolchain as of v6.0.0.

Downstream canonical JavaScript + Node.js ruleset is now https://github.com/aspect-build/rules_js.