Marcin Romaszewicz

I never thought when I wrote the original code that we'd be fetching specs over the internet, because that causes a version tracking issue, so we've always cached them locally...

This is an error from a dependency of ours, here: https://github.com/deepmap/oapi-codegen/blob/master/pkg/middleware/oapi_validate.go#L76 We use: https://github.com/getkin/kin-openapi/tree/master/routers/gorillamux Please open an issue with the kin-openapi project.

Let's make this PR flaggable via the `Configuration` structure, then it's good to go. Whenever we've made breaking changes, people complain, so let's be nice about it. I've been away...

I'm planning on having a V2 version of this library, which allows users to register Content-Type keyed decoders/encoders and this code will change quite drastically. I agree that it would...

You have to send a pull request from your own branch in your own repo, and I will pull the change. Please see https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request You don't need any push access...

Oh, this is a hard one. AdditionalProperties is very difficult to synthesize. Can you reformat your schema like this: ``` components: schemas: InnerObject: additionalProperties: true OuterObject: type: object additionalProperties: $ref:...

That's the right long term fix, it's just going to require some refactoring. Hopefully the workaround is ok for now.

Hmm, interesting, so we process them in reverse order. This will reverse processing order for anyone who regenerates their code.

I wouldn't worry about fixing this in generated code, we simply can't predict it well enough yet for all possible api specs, but we could clean up lint warnings in...

Yeah, we can add some optional flag to fix this. It would be easier to do at generation time than a post-process, but we'd have to make it optional and...