Open dropwhile opened 2 weeks ago
Yeah, this tool doesn't yet support predefined constraints... but I'm curious why it's outputting that way for you because I'm not getting what you're showing at all. This is what I get:
+ eventItemRefId:
+ type: string
+ title: event_item_ref_id
+ description: |-
+ (buf.validate.field).string.(refid) is now re-usable across many other messages
+ that all have the same field type
It looks like I need to add some code to specifically get the predefined constraints add add it to the description like the unpredefined version. I'm going to adjust your title a little bit to reflect this.
but I'm curious why it's outputting that way for you because I'm not getting what you're showing at all
My output was different because the comment in my example was just added to show some reasoning why I was doing it for the GH issue. The actual code lacked that comment block.
Oh got it! Understood! But yeah, thanks for the issue! This should be quick but I am asking buf folks about the best way to get this information since they don't yet provide an easy interface for getting constraints defined this way.
Sounds good @sudorandom! 👍
Using the rather new (released within the last week or two as part of protovalidate-go v0.8.0 from this pr) support for predefined constraints, the openapi output looks a little odd.
In and effort to reduce boilerplate, I went from a definition of this:
To this:
And the openapi output changed thusly:
Is this description change expected? If using a predefined constraint, it would be nice to retain the simpler and more easily readable description, if possible (eg. drill down to show the message and expression like before).