fix: do not rely on @npm_typescript if custom tsc is provided

[gzm0]

This is a follow-up to #675 which made the @npm_typescript repository less special.

This replaces the (hopefully) last occurrence of this special name that cannot be changed by configuration.

Alternatives I considered:

• Expose the is_typescript_5_or_greater flag on the ts_project macro: Simplest option at first, but since it is only used for config validation, that would become nonsensical.
• Add a npm_typescript_package or npm_typescript_repository parameter that would allow overriding all places where @npm_typescript// is used by default: Would offer more functionality (e.g. worker config checking), but would also be more invasive.

---

Changes are visible to end-users: yes

The change might make an incorrect warning disappear.

• Searched for relevant documentation and updated as needed: yes
• Breaking change (forces users to change their own code or config): no
• Suggested release notes appear below: no (no suggested additional release notes)

Test plan

• Covered by existing test cases

[aspect-workflows]

Test

All tests were cache hits

84 tests (100.0%) were fully cached saving 8s.

---

Buildifier      Format

[jbedard]

The primary goal is to avoid any use of npm_typescript unless required?

Would it be possible to move any of the supports_workers / is_typescript_5_or_greater logic into the macro here so it's not split throughout the macro+rule as much? I'm not sure if it's possible or worth it but something to think about.

[jbedard]

I guess it would be here that we can potentially set supports_worker = False and maybe remove some code from within the rule? Does that simplify anything?

[gzm0]

I don't think this would be correct: It is possible to supply a custom that has worker support. But if we set supports_worker = 0 here, workers would be disabled.

They way I think about this is: is_typescript_5_or_greater is a best effort configuration fix: If we can "prove" the config is wrong, we correct it and warn. If we cannot "prove" the config is wrong, we do what it says (and it might fail).

[gzm0]

The primary goal is to avoid any use of npm_typescript unless required?

Yes. We'd like to be able to use ts_project without the default npm_typescript repository. The use-case is that downstream modules can defined their own npm_typescript easily without collision (repositories generated by module extensions are not namespaced by the defining module).

Would it be possible to move any of the supports_workers / is_typescript_5_or_greater logic into the macro here so it's not split throughout the macro+rule as much? I'm not sure if it's possible or worth it but something to think about.

I don't think this is feasible unfortunately:

• Due to the use of configurations, the actual values of supports_workers / is_typescript_5_or_greater are only available inside the ts_project rule --> we have to do the check inside the rule.
• Retrieving is_typescript_5_or_greater requires "label-mangling" --> we have to do it in the macro.

One option to unmess the logic a bit would be to introduce a provider for tsc that holds the individual parts (tsc, watcher, validator, version).

• The generated typescript repositories then could expose a target with this provider.
• If manual overrides are provided in the macro, we could generate a glue-rule that puts them into the provider.
• We could allow providing a target with this provider directly in the ts_project macro (and deprecate tsc, tsc_worker and validator).

[gzm0]

Extremely minimal outline on how a provider could look: https://github.com/aspect-build/rules_ts/pull/695/files

[jbedard]

Awesome, thanks for the explanations and RFC! 👍

Switching to the RFC would be a future change, and this PR is great as-is so I'm going to merge this one.