feat(typescript): allow alternative transpilers

[alexeagle]

Fixes #3133

[thesayyn]

🤌🏻

[gregmagolan]

what about making this a dict to support arbitrary transpiler attrs such as swcrc?

transpiler_attrs = {
    "args": [...],
    "swcrc": "...",
}

[gregmagolan]

you can check the type of a param in a macro so in theory you could overload transpiler_args to support either a list (passed to args) or a dict (to support multiple attrs)

[alexeagle]

I did think about swcrc specifically, and a common case could be to pass it as a config setting bazel build --@aspect_rules_swc//:rc=.swcrc so it applies as the default for your whole build.
But of course someone will have the use case of different swcrc for two different folders of code, so yes I could see this being needed.

[thesayyn]

People who are using this attributes are most likely going to write a wrapper with defaults. Can't they just write a wrapper around swc that is passed to ts project which invokes swc with defaults? Does this sound too complex?

[alexeagle]

just changed it to transpiler_kwargs for simplicity

[gregmagolan]

nit: update doc string to reflect that testonly is also passed

[gregmagolan]

This is getting into the weeds but if you wanted to pass different tags to the transpiler then you could in theory write

ts_project(
   name = "foo",
   tags = ["foo"],
   transpiler_kwargs = {
      tags: ["bar"],
   }

and this could be supported if kwargs.get("tags", []) was merged into transpiler_kwargs if and only if transpiler_kwargs does not already have a tags.

[gregmagolan]

Complete list of "common" attributes to automatically merge into transpiler_kwargs is https://docs.bazel.build/versions/main/be/common-definitions.html#common-attributes

[alexeagle]

once we are passing through so much to the transpiler, it starts feeling like this macro is too leaky, and the user should just write their pair of typecheck(emitDeclarationOnly=true) and transpile() rules in their BUILD file.

[thesayyn]

How about instead of hiding this complexity inside ts_project, we expect users to write a simple wrapper and pass it to the transpiler? in the case of .swcrc i believe a macro like below can be written once and reused everywhere.

def swc_with_swc_rc(**kwargs):
     return swc(swcrc = "//.swcrc", **kwargs)

[alexeagle]

@tjgq I wonder if you have thoughts about this. I think we discussed the idea once?

[alexeagle]

oh @thesayyn you can use https://github.com/bazelbuild/bazel-skylib/blob/main/lib/partial.bzl for this, so that the swcrc argument is bound where you make the higher-order function, then ts_project calls that partial.

(Bazel 5 will be nicer here since you could just use a lambda)

PTAL

[thesayyn]

Upon my experimentation using our own swc rules, I realized that this won’t work out of the box. macro does not accept many of these attributes. and some of these attributes get declared twice.
https://github.com/aspect-build/rules_swc/blob/33d5a39030cb87b8d5bc2f03473429d49ab8657b/swc/swc.bzl#L38

so you end up having an error that you don’t know what to do with.

[alexeagle]

Right, the swc_rule is what exposes this API

[thesayyn]

using a dict is a really clever trick. looks neat!

looking forward see lambdas supported.

[alexeagle]

Hmm, trying this out in a downstream project, I think we didn't consider carefully enough what the shape of the dependency graph will be. If you just dep on a ts_project with this attribute set, you get .d.ts files but no way to collect up all the .js outputs. @dgp1130 since Angular has been thinking about type-check independent from the dev workflow maybe you have some minutes to chat about it with me?