-
Notifications
You must be signed in to change notification settings - Fork 767
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
Closure Migration & Typescript-ification #1414
Comments
@sampajano Is this rewrite likely to be a 2024 or 2025 thing? I’m super excited to see a revamp of this library that supports modern APIs and better interoperability. |
@bivens-dev Hi :) Likely happening in 2024 since I'm working on it already. Although internal migration needs to be completed first before I can start the Github work. Glad to hear about your interest! :) Is there any particular API that you'd like to see improved? (So far there's no plan to revamp the API yet since I'm just working on migrating the codebase to TS.) |
Ah maybe I misunderstood. Does that mean XHR rather than fetch or ideally even WebTransport for example? |
Both XHR and Fetch would be provided as options just like today. I plan to follow-up TS migration with some work to improve the Fetch/stream runtime (e.g. memory use, service worker support, etc.) given there were many issues / questions around that area. WebTransport work is separate will likely start in 2025 :) |
Hey @sampajano, is 2024 still a thing? I am bit scared about the ts migration - ts is only about the output files, right? It would be really great to still have the generator in cc to make the bazel integration easy will the js/ts api the same or will this a big migration for our frontend teams? |
@loeffel-io Hi thanks for checking..! I've actually managed to migrate a good majority of grpc-web code internally (it requires many cross-google refactors for that to happen so it's unexpectedly taking longer than i expected..), but I don't think I can finish in 2024.. And also recently I'm involved with some other higher priority tasks so I don't really have bandwidth for this at the moment.. I will aim to finish the remainder of the internal migration in early 2025, and find time to work on migrating Github workflow and releases afterwards.
Ahh thanks for checking here as well! TS migration is mainly about all the runtime and API classes here: And since we already have an TS API, which I assume many have been using: I'll definitely aim to keep it mostly the same, but no guarantee that it will be a 100% drop-in replacement — i'd bet some small migrations would still be necessary. I'll probably name the release 2.0 to reflect this fact. :) And yes, we'll still have generator in CC, although the output would probably need to be updated to reflect the TS change. Hope that answers your questions. :) |
Thank you @sampajano, sounds great! Really looking forward for the 2.0 release ❤️ Is there any chance we can publish the bzlmod in the next days? thats currently a blocker for us since we migrated to bzlmod |
It would be also great to have a grpc_web_proto_library rule in here to don't stick to rules_grpc - i could implement this like i did for dart: cbracken/rules_dart#59 (comment) |
@loeffel-io Sorry that I've been quite busy with some other priorities so I'm not quite able to work on this in the near future.. Is this something you could help contribute? I'd be happy to take a PR or follow a simple action steps if you can help me lay them out 😃 |
I think @gonzojive is already working on this |
The Closure Library has entered maintenance mode.
We're working with the Closure team on migrating our dependency to a new Github repo, containing minimal dependencies required for gRPC-Web.
In the same process, we hope to modernize our codebase into TypeScript, and overhaul our toolchain to use TS tooling, so we no longer have to depend on the Closure Compiler.
The text was updated successfully, but these errors were encountered: