Add support for extra tags and custom types

[taythebot]

This package has everything I would ever want in a OpenAPI code generator for Golang but the package doesn't leave a lot of room for flexibility.

Adding something like x-go-type and x-oapi-codegen-extra-tags like oapi-codegen that allows adding tags and overriding types would be awesome.

[LucasRoesler]

I am not opposed to this, but would love to see a more complete example (sample openapi spec and desired generated code) so that I better understand your use case.

The main example I immediately think of is trying to map to existing types from a third party package. The first that comes to mind is geojson. But, this adds a lot of complexity and moves a bit away from the original goal of this project which is "schema first, then types". I could see something like x-go-type leading to bugs in applications because the API spec doesn't actually match the Go type being used.

Having said all of that, I still want to hear more about the exact issue you have and types you are currently trying to use.

[taythebot]

I see your point about the x-go-type and how schema should be first. But the x-oapi-codegen-extra-tagswould still be useful.

In my case I'm trying to use Playground Validator instead of the built in ozoo validation. In order to use it, I need to specify the validation rules inside the struct tags.

OpenAPI

order:
  type: string
  enum:
    - asc
    - desc
  x-go-type: string
  x-oapi-codegen-extra-tags:
    validate: required,oneOf=asc desc

Generated Code

Order string `json:"order,omitempty" mapstructure:"order,omitempty" validate:"required,oneOf=asc desc"`

Even outside of Playground validator, it would still be useful as a lot of other Golang validation libraries also rely on struct tags. Giving the user freedom to choose what validation library to use would also help adoption.

[LucasRoesler]

I am curious, the models already come with validation. Your example uses required and oneOf=asc desc and both cases are possible in the current implementation. Is there another struct tag you want to add besides validation?

Whenever possible, we have tried to use plain OpenAPI and default to the built-in features as much as possible, translating them to Go as good as possible. The intent the spec should be sharable with other teams using other languages. Adding more x- fields means adding features that other generators are unlikely to ever adopt which would mean drift and potentially conflicting implementations. Validation is an area that is already mostly covered by the OpenAPI spec and we would prefer to not add a new extension for it.