OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
Is your feature request related to a problem? Please describe.
Given the following enum spec:
enum:
- HDD
- SSD
- NVME
type: string
The Go client generator will generate an enum that does strict == comparisons, so if the specified API returns NVMe instead of NVME, the response will fail validation because "NVMe" != "NVME".
Describe the solution you'd like
The Java generator supports a useEnumCaseInsensitive option; when that option is enabled, the generator will use case-insensitive equality checks for string enums. Copying that feature into the Go generator would enable generator users to opt in to case-insensitive comparisons for string enums.
Describe alternatives you've considered
Things I've tried:
First I tried adding NVMe to the list of enum items, but that didn't work because the generated Go enums use constants where the name is the uppercased enum value, so both NVMe and NVME end up with the name MYENUM_NVME, leading to an error MYENUM_NVME redeclared in this block.
Then I tried using custom templates to implement x-enum-as-string support. That's feasible with custom templates, but the extent of the template changes convinced me that that support would be better implemented in the generator than as a template-only change.
Is your feature request related to a problem? Please describe.
Given the following enum spec:
The Go client generator will generate an enum that does strict
==
comparisons, so if the specified API returnsNVMe
instead ofNVME
, the response will fail validation because"NVMe" != "NVME"
.Describe the solution you'd like
The Java generator supports a
useEnumCaseInsensitive
option; when that option is enabled, the generator will use case-insensitive equality checks for string enums. Copying that feature into the Go generator would enable generator users to opt in to case-insensitive comparisons for string enums.Describe alternatives you've considered
Things I've tried:
NVMe
to the list of enum items, but that didn't work because the generated Go enums use constants where the name is the uppercased enum value, so bothNVMe
andNVME
end up with the nameMYENUM_NVME
, leading to an errorMYENUM_NVME redeclared in this block
.x-enum-as-string
support. That's feasible with custom templates, but the extent of the template changes convinced me that that support would be better implemented in the generator than as a template-only change.Additional context