ts-proto VS protobuf-ts

I created it so that I could use `protoc` and `ts-proto` to convert the otel proto files into typescript files.

Re libraries incompatible with certain typescript versions - e.g. protobufjs fix - it’s been my experience that you want to try and only use compilers specific to each library and compile libraries separately. It’s unfortunate but the JS community often tries to run all JS for a project through the same single compiler tool chain, using one global version of the compiler instead of relying on and effectively linking the JS output for each library. Unless you routinely rewrite third-party libraries to match your toolchain’s expectations, you’re going to have a hard time doing that.

For a library that generates code, that’s a special case, as the code it generates must target a particular language version. You have three choices: 1. Upstream a fix as you propose; 2. Side-by-side install both TS 4.6 and TS 4.7 using workspaces or sub-projects and have some of your code compile with 4.6 and then link the results or 3. Find a replacement that is updated to 4.7. For example, https://github.com/stephenh/ts-proto has 4.7 support listed in its readme.

With ts-proto, I can pass a --ts_proto_opt=outputServices=generic-definitions as a flag to protoc to generate "generic service definitions". These definitions contain descriptors for each method, which allows to generate server and client stubs at runtime, and also generate strong types for them at compile time.

Curious to see their typescript implementation and how it compares with https://github.com/stephenh/ts-proto which works great for grpc-web.

I'm planning on modding https://github.com/stephenh/ts-proto to use https://github.com/ianstormtaylor/superstruct on the client.

We also use protobufs and typescript, so we use ts-proto for codegen + binding to grpc services.

Fwiw I maintain ts-proto (https://github.com/stephenh/ts-proto/) and it'd be cool to have the functionality you're building supported in ts-proto at somepoint, if you're curious/want to poke around/etc. :-) Right now there is grpc support via the improbable-eng grpcwebproxy, but supporting GCP's transcoding as well would be great.

DX for front or back end? The beauty of tRPC is that the types are derived/inferred from the backend runtime code (like, as you type). It would be nigh impossible to do that with grpc(-web) using proto files as the source of truth.

It's possible there's a project out there which could automatically produce proto files from something like zod, json-schema, etc. which could be directly interpreted by TS to provide similar (as you type) DX while still allowing some other language backend to consume the derived proto files (though the DX there would be less than ideal).

If you're just looking for similar TS clients/interfaces for grpc-web then I'd recommend https://github.com/timostamm/protobuf-ts which operates on plain JS objects (no new MyMessage().serialize(), instead the code generator mostly produces TS interfaces for you to work against: const myMessage: MyMessage = pojoConformingToInterface; const binary = MyMessage.toBinary(myMessage);)

https://github.com/timostamm/protobuf-ts (RpcMetaData) https://github.com/timostamm/protobuf-ts/blob/main/MANUAL.md

The second big difference is that we now have auto-generated client and server stubs. For this task, I chose to use buf and the protobuf-ts plugin in order to generate idiomatic Typescript classes and objects. Not only do these classes describe the types we'll use in the server and client, but also includes the actual gRPC implementations used to serialize and send messages back and forth across the wire.

I wouldn’t use grpc with web if you can avoid it. If you’re looking for a ts protobuf library I can recommend this one https://github.com/timostamm/protobuf-ts

https://github.com/timostamm/protobuf-ts looks interesting too.

I'd recommend looking into protobuf-ts (Timo from Buf) or protobuf-es (Buf maintained).

Use a GRPC library for frontend, assuming you want to go with Typescript take a look at https://github.com/timostamm/protobuf-ts Frontend frameworks like Angular/React/Vue don't define what and how to implement backend communication. You can use what you want and how you want it.

And there's also this which is by the same author but came before it: https://github.com/timostamm/protobuf-ts

The latter has code-generation for services and has various transport packages for twirp, grpc, and grpc-web.

This looks very interesting! Anything that can move people away from protobuf.js (which seems to no longer be maintained and depends on prototype values for "default values" meaning that you can't send deserialized protobuf messages to/from web workers) and the "native" JS codegen by Google (which produces code that is both very slow and a awkward to use) is a win in my book.

We're currently using https://github.com/timostamm/protobuf-ts which has been fantastic. It's codegen is dependent on the protoc binary as it is implemented as a protoc plugin, but the code it generates passes the protobuf conformance tests. The generated code also outputs plain objects when deserializing protobuf messages which means it works perfectly when sending stuff to/from web workers. It also has grpc, grpc-web, and twirp clients.