-
Notifications
You must be signed in to change notification settings - Fork 519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[governance] resolve ownership of rules_typescript #2120
Comments
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
Perhaps. I think any of these options are an improvement and it depends on who volunteers. |
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. |
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
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? |
You can see from the history of rules_typescript repo that it still gets occasional syncs of code from Google |
@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 |
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. |
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. |
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.
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.
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. |
No longer fetch the rules_typescript repo from github, which is inactive and should be archived. Since we switch to local_repository which doesn't have a patches feature, the patches need to be applied to the sources as local modifications now. Fixes bazel-contrib#2120
No longer fetch the rules_typescript repo from github, which is inactive and should be archived. Since we switch to local_repository which doesn't have a patches feature, the patches need to be applied to the sources as local modifications now. Fixes bazel-contrib#2120
No longer fetch the rules_typescript repo from github, which is inactive and should be archived. Since we switch to local_repository which doesn't have a patches feature, the patches need to be applied to the sources as local modifications now. Fixes bazel-contrib#2120
fixed for 3.x by vendoring the code, rules_typescript repo can be archived |
to clarify, we decided on option 1a above, the code is now forked and maintenance will happen in rules_nodejs independent of google3. |
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:
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
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 withts_library
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 thets_project
andts_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.The text was updated successfully, but these errors were encountered: