Plugin request for sudorandom/protoc-gen-connect-openapi

[mfridman]

This plugin has been mentioned several times in the Slack channel. I created this issue to assess its potential as a plugin and to gauge community feedback.

It might not be possible because from a cursory glance it required an auxiliary yaml file.

Mandatory

Where is the source code for the plugin?

https://github.com/sudorandom/protoc-gen-connect-openapi

Optional

Does the plugin have a valid semver version?

Yes, https://github.com/sudorandom/protoc-gen-connect-openapi/releases/tag/v0.7.2

Does the output of this plugin depend on any other external libraries?

Not sure

[sudorandom]

Hi, I authored this plugin! Adding a few more details:

Does the output of this plugin depend on any other external libraries?

I believe the answer is no.

-- potentially irrelevant info -- From a Go point of view, this plugin uses this library to generate OpenAPI JSON/YAML: github.com/pb33f/libopenapi. All Go libraries can be found in go.mod. All libraries, however, are written in Go.

This plugin uses options from gnostic, protovalidate, and google/api/annotations.HttpRule from gRPC/HTTP transcoding so all of those options can influence output. -- end potentially irrelevant info --

It might not be possible because from a cursory glance it required an auxiliary yaml file.

It does not require this YAML file. Some examples show using a base YAML file in order to more easily define some things in the output without requiring adding options to your protobuf file(s).

[nadilas]

Hi @mfridman, could we revisit this? OAS3 is still a painpoint.

[mfridman]

Thanks for flagging it, and thank you for the additional details. I can't promise anything, but I'll bring it up with the team.

[ehmo]

Hi, any news on this? I would appreciate if it was added to the registry.

[soggycactus]

+1 - would also love if this was added to BSR

[george-oakling]

Hi, any news on this?

[mfridman]

For those who upvoted this issue or requested this plugin: Since we don't allow auxiliary files in the BSR [^1], would you still find this plugin useful as a Remote Plugin without the ability to use it with a .yaml file?

[^1]: Plugins that access the file system, make network requests, or otherwise cause the CodeGeneratorResponse to depend on information other than what is in the CodeGeneratorRequest, don't conform to the protocol and are not supported. Reference

[yordis]

@mfridman to be honest, I do not understand the situation, only speaking from the end user experience and BSR, it would help to use remote plugin in our buf.gen.yaml file and avoid the issues of developers having different versions

[sudorandom]

@mfridman I would like to point out that this impacts two options:

• base
• override

If the plugin has a way to detect that it's running in "remote plugin" mode then I can add a more helpful message explaining that those two options aren't supported in this mode and offer an alternative, which is using gnostic OpenAPI annotations in your protobuf or using the plugin locally.

[sudorandom]

Oh, or alternatively, I can disable those options if given a specific go tag when building. Would that make the plugin conform?

[mfridman]

Quick update, the plugin should be available on the BSR now:

https://buf.build/community/sudorandom-connect-openapi

ps. thank you @sudorandom for putting this together and fielding questions.