Skip to content
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

Open
sampajano opened this issue Mar 19, 2024 · 10 comments
Open

Closure Migration & Typescript-ification #1414

sampajano opened this issue Mar 19, 2024 · 10 comments
Assignees
Labels

Comments

@sampajano
Copy link
Collaborator

sampajano commented Mar 19, 2024

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.

@bivens-dev
Copy link

@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.

@sampajano
Copy link
Collaborator Author

@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.)

@bivens-dev
Copy link

Ah maybe I misunderstood. Does that mean XHR rather than fetch or ideally even WebTransport for example?

@sampajano
Copy link
Collaborator Author

sampajano commented Jun 10, 2024

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 :)

@loeffel-io
Copy link

loeffel-io commented Dec 3, 2024

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?

@sampajano
Copy link
Collaborator Author

@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.


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?

Ahh thanks for checking here as well!

TS migration is mainly about all the runtime and API classes here:
https://github.com/grpc/grpc-web/tree/master/javascript/net/grpc/web

And since we already have an TS API, which I assume many have been using:
https://github.com/grpc/grpc-web/blob/master/packages/grpc-web/index.d.ts

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. :)

@loeffel-io
Copy link

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

@loeffel-io
Copy link

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)

@sampajano
Copy link
Collaborator Author

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

@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 😃

@loeffel-io
Copy link

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

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants