[Bug]: Dependents of modules that use aspect_rules_ts cannot use aspect_rules_ts themselves

[sbarfurth]

What happened?

When a module that uses aspect_rules_ts depends on a module that also uses it, builds result in the following error:

Error in repository_rule: A repo named npm_typescript is already generated by this module extension at ...

Version

Development (host) and target OS/architectures: Linux

Output of bazel --version: 8.3.1

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

Language(s) and/or frameworks involved: Bazel

How to reproduce

git clone https://github.com/sbarfurth/aspect_rules_ts_issues.git
cd aspect_rules_ts_issues/module_b
bazel build //:consumer

Check https://github.com/sbarfurth/aspect_rules_ts_issues for more details.

Any other information?

When a module depends on a module that uses aspect_rules_ts, the depending module cannot themselves depend on aspect_rules_ts. This is because the repository rule used by aspect_rules_ts cannot be called more than once in the module dependency tree with the same name. The rules in aspect_rules_ts depend on the default name and therefore changing it is cumbersome.

This was previously filed as #483.

[alexeagle]

Dupe of #842

[sbarfurth]

This isn't a duplicate. This is about the repository name being a collision by default and changing it being annoying due to defaults of ts_project. Could you explain why this is a duplicate? They can be tackled together, but they're not the same issue afaict.

[jbedard]

I think they are quite different and will have different solutions (even if in the same PR). Note #844 is a potential solution to #842 but does not fix this one.

[sbarfurth]

Thanks for taking a look @jbedard. Happy to help if I can. Do you have any ideas for this one? I'm wondering how the intended behavior should be, then we can think about implementation.

I'm guessing for this particular one, other rulesets with toolchains must have solutions. I'd assume something like the Go ruleset works similarly. Looking at their code, it seems they do provide a repo but it's not meant to be depended upon. Instead they offer a toolchain to provide dependencies. Perhaps that could solve the issue of rule defaults as well. Set up a toolchain and a simple resolution algorithm (e.g. pick newest) and then use it in the rules.

Not sure if that's enough to solve the issue, but I think it would alleviate the need to depend on the repo from modules which should remove the conflict.

[jbedard]

I'm not certain what the correct behaviour would be.

One module (A) might have it's own ts_project(tsc) while another module (B) or the root module (R) might have a separate ts_project(tsc). Those modules might need different tsc binaries in order to compile as-expected, and unlike some languages there is normally no reason to force a single tsc binary/version across all the modules.

I thought each module declaring a dependency on rules_ts would have it's own module-scoped version of npm_typescript such as module_a~npm_typescript. I don't understand why that's not the case and they are conflicting?

[sbarfurth]

Could we expose tsc and friends directly from aspect_rules_ts? Then there'd be no need for the repository in dependents. Obviously wouldn't allow self-selection of the version I guess.

Alternatively, a toolchain seems right. Just needs the right resolution algorithm. Maybe offer a "most_recent" toolchain and a locally registered version? And then default the rule to one of them. Also removes the need for a repo.