[governance] resolve ownership of rules_typescript

[alexeagle]

This issue combines a bunch of discussion, such as that from @pauldraper in #2038

rules_typescript is a strange beast due to organizational issues. It represents the part of rules_nodejs that has the source-of-truth in Google's internal repo. Merges to it require Googler intervention, and there is no Google team staffed to spend any time on it. There's a bunch of history here including my departure from Google, and subsequently making a more community-idiomatic ts_project replacement rule where I'd rather spend my volunteer fun hours.

Similar to last week's divestment of rules_apple it's time to consider our options, which I'll try to summarize and orthogonalize:

1. "fork" - move rules_typescript code into rules_nodejs and start making whatever breaking changes we want, stop syncing with Google-internal and let them diverge. Keep supporting and evolving rules like ts_library.
   1b) "donate" - like "fork", but instead of supporting those rules in rules_nodejs, find new OSS maintainers for the rules_typescript codebase and have them continue to work in that repo. In this case we remove the rules_typescript dependency from rules_nodejs
2. "divest" - find the "frontend" of rules that depend on rules_typescript like ts_library, ts_devserver, and put them into rules_typescript. Make it independent of rules_nodejs, with the understanding that no one at Google maintains it and it's unlikely to accept any changes. This is basically a slow way of killing this code and divesting our responsibility for maintaining and supporting it, which none of rules_nodejs team has time for.
   2b) "obviate" - like divest, but first make an excellent migration path off of rules_typescript rules, like by getting ts_project performance- and feature-parity with ts_library
3. "escalate" - get someone at Google to contribute to Bazel JS/TS development. I tried this for a couple years as a Googler, but maybe something has changed since I left that makes it more feasible.

Ideally we would get some discussion with Google Bazel or nodejs teams before making this decision. I think everyone would like option 1 the best, but honestly I don't think we have resources to support it and may have to do 2.

Note that in most of these scenarios, we have to split the @bazel/typescript npm package in half, since it currently contains both the ts_project and ts_library rules, the former is source-of-truth in rules_nodejs and is a small shim and reasonable maintenance burden, and the latter is not.

[pauldraper]

As stated elsewhere, I'd prefer to see the clean separation of JavaScript and TypeScript. The minimizes the surface area of rules_nodejs (rules_javascript) and helps to ensure the abstraction will work well for other compile-to-JS citizens: Kotlin/JS, Scala.js, PureScript, ClojureScript etc.

That is, I'd prefer

• rules_typescript is open to Google-incompatible changes
• ts_project moves to rules_typescript
• rules_nodejs has no dependency on rules_typescript; rather, the reverse

I think everyone would like option 1 the best, but honestly I don't think we have resources to support it and may have to do 2.

Perhaps. I think any of these options are an improvement and it depends on who volunteers.

[alexeagle]

Practically speaking, multiple repos makes CI hard. I want to gate rules_nodejs changes on whether they break a TS rule, or an example that uses TS.
Also it's hard to have no dependency from rules_nodejs to rules_typescript because we write our own tooling in TS. We need at least a dev dependency on it, and the resulting cycle is annoying to deal with.
Finally, we have nice development flows in the rules_nodejs monorepo, like versioning things together, pushing releases, generating documentation, labelling/triaging issues, and a bunch more. It's hard to do all those governance and setup tasks again in another repo which is why monorepo FTW
If we find a clean way to resolve those issues I'm supportive of that change.

[matthewjh]

Hi @alexeagle, I have some questions about this. I (+our company) am a new user of this project, so please bear with me. Of course, as we are migrating all our UI code to Bazel and rules_nodejs/typescript, we are very interested in what happens here.

The docs say

ts_library is an open-sourced version of the rule we use to compile TS code at Google.

which, I suppose, implies that at some interval, there would be a sync up between the Google "source of truth" and the open-sourced copy. Are you saying that this is no longer the case or will not be the case any more, due to lack of Google resources allocated to doing so?

[alexeagle]

You can see from the history of rules_typescript repo that it still gets occasional syncs of code from Google

[alexeagle]

@pauldraper @JaredNeil we just discussed this in the weekly collaborator meeting and it seems like we are close to deciding on #1 or #1b - do you have enough interest and time to help maintain a separate rules_typescript layer? Otherwise we'll probably fold it into rules_nodejs, still happy to accept contributions in our monorepo of course

[JaredNeil]

I think we (Lucid Software) are fine with option 1. While I also feel it would be nice (in theory) to have separate workspaces, the practical reasons you listed lead me to believe the monorepo approach has enough benefits to be the better option.

My biggest concern would be that "whatever breaking changes we want" could end up being hard for us to keep up with. Because our usage is similar to Google-internal, a breaking change for them is more likely to also be a breaking change for us than most users. Knowing that, we can be better at keeping up with changes to make sure we aren't left behind on an old version because of breaking changes.

[alexeagle]

We'll continue to be very careful with breaking changes, I just mean we won't be bound to wait for someone with google3 access before we can merge those.
With your continued involvement we can also pre-flight changes on the lucid repo before we ship a major.

[pauldraper]

Practically speaking, multiple repos makes CI hard. I want to gate rules_nodejs changes on whether they break a TS rule, or an example that uses TS.

And yet bazelbuild has many repos.

Choose boundaries, separate repos by those boundaries, document those boundaries as APIs, and then author tests to verify their adherence. Most uses of rules_nodejs are and will always be outside the scope of the repo itself.

Also it's hard to have no dependency from rules_nodejs to rules_typescript because we write our own tooling in TS. We need at least a dev dependency on it, and the resulting cycle is annoying to deal with.

The fundamental bootstrapping problem remains the same, no matter what workspaces they are in. Updating dependencies is annoying, but if the rules_javascript/rules_typescript APIs are changing that much...that spells difficulty for the downstream users of them as well.

Finally, we have nice development flows in the rules_nodejs monorepo, like versioning things together, pushing releases, generating documentation, labelling/triaging issues, and a bunch more.

Ultimately, it comes down to whether Javascript/Typescript are significantly the "same" project/API or if they are different. Java/Kotlin were thought to be "significantly different", so they are in two separate repos.

But I can't contribute time to this, so my 2 cents are worth about that much.

[alexeagle]

fixed for 3.x by vendoring the code, rules_typescript repo can be archived

[alexeagle]

to clarify, we decided on option 1a above, the code is now forked and maintenance will happen in rules_nodejs independent of google3.