google.protobuf.Timestamp coming up as Date | undefined
Hello!
Currently using ts-proto and it's been great! Reading into the decision to default to have useOptions=false by default and I totally think it's the right call. Can't tell you how many times I've gotten bit by this in Golang.
However, by default ts-proto seems to generate the google.protobuf.Timestamp into Date | undefined, even if it's "required" so to speak (I know proto3 has no definition of required, but it does seem like ts-proto is treating all the non optional fields as required, which is also a great call)
Wondering if there's a way to have the google.protobuf.Timestamp generate as a Date if no optional tag is provided, and Date | undefined if the optional param is provided
Cheers!
EDIT: Seeing this as a highlight in the readme under "poor man's optional types" but with optional types being supported in proto, I think this could be unwound?
Hi @JakeCooper ; sorry for the late reply!
Hm...it's been awhile since I've thought about this, but I wouldn't be surprised if the issue is that Timestamp is fundamentally a message, and so while ts-proto can opinionated-ly make primitives "required", I think messages are probably just another thing all together.
If you'd like to dig in and see if there's a way to do this, that'd be great, bit I'm not sure there'd even be a way for us to differentiate "required timestamps" vs. "optional timestamps" in the protos.
@stephenh i think this is related to required messages not being available. Can you elaborate a bit, please? This behavior generates a lot of boilerplate.
Hi @incompletude , sorry, I think I need to close this out, b/c there just is not a way to do it with proto behavior.
I was thinking that you could somehow teach this line of code:
https://github.com/stephenh/ts-proto/blob/main/src/types.ts#L669
That "any field with type google.protobuf.Timestamp should be just Date instead of Date | undefined", and that would get your ts-proto types to be dueDate: Date.
However, the issue is that protobuf's are fundamentally for interacting with other systems, and another system could easily send a message "without the dueDate message field set", and there is no obvious fallback for "...what Date to use when there is no Date on the wire?".
Primitives can do this because "the obvious fallback for a missing number is 0", "the obvoius fallback for a missing string is empty string", etc.
I think optional fields should be marked as such, and if a message is sent "without the dueDate message field set" in a non-optional field, an exception should be thrown. but i understand there is no obvious fallback value for non primitives.