Strict Client Types

[JakeCooper]

I'm unsure if this is simply a property I'm missing to invoke, but it seems all my generated clients have optional fields?

Generate Command:

echo "Generating $service_name TypeScript proto file!"
../../node_modules/.bin/grpc_tools_node_protoc \
    --plugin=protoc-gen-ts_proto=../../node_modules/.bin/protoc-gen-ts_proto \
    --ts_proto_out=../../gen/typescript/proto/$service_name \
    --ts_proto_opt=outputServices=generic-definitions \
    --ts_proto_opt=esModuleInterop=true \
   proto/*.proto

Would be nice if we could have them strictly typed and only optional if we're using the optional keyword for proto

Thanks for the lovely library! It's far and away the best TypeScript one (No idea why it doesn't have more love?!??!)

[aikoven]

Client requests and server responses are automatically wrapped with fromPartial when using ts-proto. You can opt out from this by using --ts_proto_opt=outputPartialMethods=false flag. We could also provide a helper that strips fromPartial method from service definitions, so that you could still use fromPartial where you need it.

But consider that in proto3, all fields are actually optional. The optional keyword does not make a field "optional" in TypeScript sense, it just makes it possible to distinguish between missing and empty (default) values. In my opinion, it's better to always create objects using fromPartial instead of direct object literals: this way if a new field is added to a message (which is not a breaking change in Protobuf), it would not break your code.

Thanks for the lovely library! It's far and away the best TypeScript one (No idea why it doesn't have more love?!??!)

Thanks. It's still pretty young, but we already widely use it in many projects in my org. And we are determined to evolve it, add more official middleware etc. Hopefully, it gets more users in the future :)