[Feature Request] Typescript Support about protovalidate

[nicksnyder]

Working on this is on our roadmap, but progress is blocked on a solution to bufbuild/protobuf-es#397 (which is also on our roadmap). We will share any updates when we have them.

[nicksnyder]

Rough guess is that we will be unblocked sometime in Q1. Appreciate the offer to help and will post to the issue if we could use help when the time comes.

[nicksnyder]

Yes, supporting Protovalidate in TypeScript entails having a high quality open source CEL interpreter that works in all the environments we want (aka doesn't require Node.js APIs and doesn't require WASM). We are also unaware of any existing open source project that meets these requirements and so have already invested some time building our own implementation. We would open source this CEL implementation at the same time that we would open source support for Protovalidate TypeScript (which currently doesn't have a concrete timeline associated with it).

[nicksnyder]

Would you folks be open to adding library functions that don't depend on protobuf-es while that blocker exists?

No, we are focusing our attention on improving protobuf-es and are actively working on a solution to the blocking issue.

[nickwinger]

Good to hear that, maybe i can also contribute. It seems like zod is popular these days, you would instantly also have validation up to the frontend: https://zod.dev/

[akosyakov]

@elliotmjackson Hi there! Is there already something available to try out?

[kwhitehouse]

Hi there! Having typescript support for protovalidate would be fantastic.

I noticed in the linked blocker above that @protobuf-ts correctly includes options in the generated typescript. I was able to successfully test this out locally, such that my generated Typescript code contained custom proto options I defined using protovalidate syntax.

Would you folks be open to adding library functions that don't depend on protobuf-es while that blocker exists? For example, instead of providing a function public ValidationResult validate(Message msg) within the library, you could instead expect that:

• Users of your library would define their validation in their .proto files (no change here).
• Users of your library would be responsible for generating FieldConstraints and MessageConstraints and such. (As a user, I would rely on protobuf-ts to help me do this with its helper functions like readFieldOption.)
• Your Typescript protovalidate library would provide methods like public ValidationResult validate(fieldValue Value, fieldConstraints FieldConstraints).

I believe with this structure, your library wouldn't have any need to inspect what options were defined on a given proto message. Instead, clients would be responsible for doing this themselves, and your protovalidate Typescript library would simply provide the validation component. Long-term it would obviously be wonderful to address bufbuild/protobuf-es#397 and have a simple validate method available that could parse custom proto options, similar to what's present in the Python and Golang and Java libraries you folks have developed. But it would definitely be helpful to have a stop-gap solution here that at least provided partial support for users of your protovalidate ecosystem!

[kwhitehouse]

Would you folks be open to adding library functions that don't depend on protobuf-es while that blocker exists?

No, we are focusing our attention on improving protobuf-es and are actively working on a solution to the blocking issue.

Thanks Nick, that's great to hear! Do you folks have any ETA on when you might have the blocking issue resolved, and when it might be possible to start developing the protovalidate-typescript library? (I'd be happy to help out with the latter if you're looking for contributors!)

[kwhitehouse]

Awesome, thanks, I'll check back in on this ticket in Q1!

[svdney4]

Since protovalidate relies heavily on CEL does this mean that a CEL typescript evaluator is being developed as well?
And will there be a standalone version of the evaluator?
We have the need for a javascript/typescript CEL evaluator in our project but we can't seem to find a robust implementation at the moment.