You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be really cool if the generated TypeScript types were aware of protovalidate rules.
For example
dropping the ? optional qualifier for message fields with required
dropping the undefined case for oneofs with required
generating Extract<> types and Omit<> types for fields with in/not_in
There are probably other rules that can be translated into type constraints (e.g. const), but those are the ones that we're making use of.
It makes the resulting code a lot easier to work with if you have strict TypeScript config because you'll get compile errors rather than runtime errors if you fail to set a required field on a message, and you don't have to deal with impossible situations like something potentially being undefined that you know can never be undefined because of the validation rules.
We're currently achieving this by doing some nasty regex-based post-processing of the generated code but I would love to stop doing that 🙈
The text was updated successfully, but these errors were encountered:
I'm not sure that the generated types should be modified by protovalidate rules. There's no guarantee that a given message has been validated before serialization, so you could easily get a runtime error when parsing a message that isn't valid.
But I've been thinking that protoc-gen-es could generate *Valid types that honor protovalidate rules, similar to JSON types. Protovalidate's validate function could act as a type guard, and pick up the *Valid type. Of course you could use the *Valid types without running validation yourself if you are certain that data is already valid.
It would be really cool if the generated TypeScript types were aware of
protovalidate
rules.For example
?
optional qualifier for message fields withrequired
undefined
case for oneofs withrequired
Extract<>
types andOmit<>
types for fields within
/not_in
There are probably other rules that can be translated into type constraints (e.g.
const
), but those are the ones that we're making use of.It makes the resulting code a lot easier to work with if you have strict TypeScript config because you'll get compile errors rather than runtime errors if you fail to set a required field on a message, and you don't have to deal with impossible situations like something potentially being
undefined
that you know can never beundefined
because of the validation rules.We're currently achieving this by doing some nasty regex-based post-processing of the generated code but I would love to stop doing that 🙈
The text was updated successfully, but these errors were encountered: