In the current typings for openapi-typescript-fetch a hard-coded 'application/json' string is used to infer the response types. Which breaks in the case of our schema...
This PR adds a templated literal to accommodate for situations where something other than 'application/json' is used, while remaining backwards compatible.
OpenAPI spec supports content negotiation, in my use case we use this to support API versioning.
So, our spec results in a generated schema type such as this:
In the current typings for openapi-typescript-fetch a hard-coded 'application/json' string is used to infer the response types. Which breaks in the case of our schema...
This PR adds a templated literal to accommodate for situations where something other than 'application/json' is used, while remaining backwards compatible.