Add -module flag to protoc-gen-openapiv2 plugin

[zerospiel]

🚀 Feature

Current usage of protoc-gen-openapiv2 plugin is not consistent with protoc-gen-grpc-gateway due to lack of -module flag, in this case, if you use both of plugins you'll getting generated files file.pb.gw.go and file.swagger.json in different directories within a project if input proto file has go_package option.

E.g. the following simple command:

> go list -m
github.com/user/repo

> protoc --proto_path ./protos \
--go_out module=github.com/user/repo:. \
--go-grpc_out module=github.com/user/repo:. \
--grpc-gateway_out logtostderr=true,module=github.com/user/repo:. \
--openapiv2_out logtostderr=true:. \
./protos/pkg.name.v1/file.proto

With file.proto having option go_package = "github.com/user/repo/some_pkg_dir;some_pkg_name";

Produces the next structure:

├─ some_pkg_dir/
│       ├─ file.pb.go
│       ├─ file_grpc.pb..go
│       ├─ file.pb.gw.go
│
├─ pkg.name.v1/
│       ├─ file.swagger.json

And it looks not so great IMO and requires additional invokes of mv command from a user.

Support of the -module option for the protoc-gen-openapiv2 plugin should mitigate this problem and all files after generation will be in the same directory.

If I'm correct, protoc-gen-openapiv2 should use the google.golang.org/protobuf/compiler/protogen package as it's already done in protoc-gen-grpc-gateway's code.

[johanbrandhorst]

Hi Mihail. I would actually push back a little bit on the premise here that protoc-gen-openapiv2 should behave like the Go generator. protoc-gen-openapiv2 is not a go generator, and it should not care about the go_package option in the protofile. The only job of the protoc-gen-openapiv2 generator is to translate the http.proto and our custom annotations into a OpenAPIv2 compatible JSON file.

Given that, I would also challenge the suggestion that the generator should be rewritten with the new Go proto generator framework in mind. That framework is great for writing plugins that generate Go code, since it deals with imports and common flags for you. However, this is not the job of protoc-gen-openapiv2.

As such, I don't think this is a use case we want to support. I hope you understand and that you can adjust your workflow accordingly. I will close this issue, but please let me know if you still think there's a good reason for us to add this flag and I will reopen the discussion.