[BREAKING CHANGE] Reusing Custom Validation Rules

[justmumu]

Feature description:
I don't know it is possible. But reusing validation rules would be nice.

Problem it solves or use case:
A validation rule may be suitable for multiple fields.
Currently, same custom cel expression duplicated to all fields. This makes harder to maintain custom validation rules.

Proposed implementation or solution:
I don't know if there is a way to extend the rules. But if we could extend the rules, we could apply the rule to the field as normal standard constraint.

For Example;

string xxx = 1 [(buf.validate.field) = {string.<custom_cel_id>: true}];

Contribution:

Examples or references:

Additional context:

[mfridman]

Found myself looking for a similar solution. I'd love a way to write a reusable (custom) rule and apply that at the individual field level across a project.

I suppose one alternative is to create a message, add validation to the field(s), and reuse the message across the project. But this is less than ideal because oftentimes it's a specific field you'd want to validate and retrofitting this to an existing project is a bit of a pain.

Ideally, we could define a set of rules in a custom_validate.proto (call it whatever) and be able to reuse that.

[elliotmjackson]

I agree, this would be a great feature. It's definitely something we are looking at.

[lucatk]

is there any workaround/ way to reuse rules at the moment?

[ramilmsh]

@lucatk I assume that the solution would be to fork the repo and add them here:

https://github.com/bufbuild/protovalidate/blob/main/proto/protovalidate/buf/validate/validate.proto#L2469

As far as I understand, all rules in this repo are deep down cel rules. So you can just create another cel expression for the type you want.

However, i don't know if this would propagate to language libraries, although i assume they would, since i imagine they simply get cel expressions from proto and use them to validate

If i end up trying it, I will report back

@elliotmjackson can you confirm or refute, please?

[rodaine]

A solution is next on our roadmap to add support for making portable rules that can be shared across multiple fields/messages. Stay tuned!

Depending on the implementation, forking might work, but in some circumstances (particularly Go) the protobuf library is very finicky about the source of the types and may panic.

[lucatk]

any updates/timeline on this @rodaine?

[rodaine]

Nothing concrete yet. I have been testing out some potential strategies here, but the real sticking point is getting the ergonomics right balanced with preventing mistakes that can't be caught until runtime (or via a linter).

[glerchundi]

Thanks @rodaine for working on this!

A specific use case is google.api.resource and google.api.resource_reference like usages. You define one or more resource name patterns in the entity itself and reference it multiple times all over the specification. Even crossing the package boundaries. Would your current specification/ergonomics plan support this or is out of scope?

In this case we solved it in the old protoc-gen-validate was by adding a custom validation point and creating a custom generator.

[rodaine]

Yep, it'd work across package boundaries. Essentially, the goal is for a user to define their own custom extension options on messages and/or fields and decorate that extension with protovalidate constraints and cel expressions. That extension then can be imported anywhere and protovalidate libraries would detect it and apply the rules.