protoc-gen-validate VS ts-proto

My understanding is that the powers that be within Google have decided that validating messages is outside the scope of schemas and serialization. protoc-gen-validate provides a portable way to perform validation: https://github.com/bufbuild/protoc-gen-validate

The problem with required fields is it kicks the can down the road when you want to deprecate a field. Keeping everything optional is much, much better for everyone in the long run.

I built a (go) very rough draft to support 3.1 + a json pointer pkg to support a refactor that was in progress before I bailed on the idea. The amount of effort to get a conventional API was dwarfing that of grpc, especially with protoc-gen-validate.

Yes, I am currently using this. I prefer something like this https://github.com/envoyproxy/protoc-gen-validate

We've been using Rust with protobuf, but had to write lots of conversions from protobuf struct to actual DTO, since prost generates Options for nested types, and does not really support custom types. So I extended prost with the options that we needed. I might aim to also support protoc-gen-validate.

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.