Invalid enums generated when the underlying enum specifier contains no alphanumerics

[ChrisKitching]

Given an openapi fragment like:

    "Norm" : {
      "type" : "object",
      "required" : [ "condition", "value" ],
      "properties" : {
        "condition" : {
          "type" : "string",
          "example" : "<=",
          "description" : "Condition norm for this indicator.",
          "enum" : [ "<=", ">=" ]
        },
        "value" : {
          "type" : "number",
          "format" : "float",
          "example" : 0.6,
          "description" : "Service norm for this indicator."
        }
      }
    },

The following invalid typescript is produced:

export namespace Norm {

    /**
     * Condition norm for this indicator.
     */
    export enum condition {
        _ = '<=',
        _ = '>=',
    }


}

The full openapi spec being used can be found here: https://api.bol.com/retailer/public/apispec/Retailer%20API%20-%20v7

I invoked it like:

yarn openapi \
  --input https://api.bol.com/retailer/public/apispec/Retailer%20API%20-%20v7 \
  --output "$OUT_DIR" \
  --name BolRetailerClient \
  --client axios

This schema works fine when --useUnionTypes is used, since you then get condition: '<=' | '>=';.

Can we please enhance the code generator to detect when it has failed to deduce unique names for every enum value, and either:

• Codegen enums that lack meaningful names (like condition above) as union types, even when codegenning in enum mode
• Raise an error informing the user that this specification must be codegenned in union-type mode.

At present, it just silently generates the broken typescript and you have to work backwards from the compile error to infer the need for the union-types flag, which isn't ideal.

[alexander-lebed]

I confirm the issue. In my case:

...
operator:
  type: string

  enum:
    - '='
     - '!='
     - '<'
    - '>'
    - '<='
    - '>='
    - '~'
    - '!~'
    - '^'
    - '!^'
    - '$'
    - IN

=>

...
export enum operator {
    _ = '=',
    _ = '!=',
    _ = '<',
    _ = '>',
    _ = '<=',
    _ = '>=',
    _ = '~',
    _ = '!~',
    _ = '^',
    _ = '!^',
    _ = '$',
    IN = 'IN',
}

[tjesposito]

Looks like it's replacing non-alphanums with _. A few examples, from Java to OAS3 and then to TS; hopefully this helps anyone hitting this as a gotcha. Worked around it by just using actual words instead of <, > etc.

GREATER_THAN_A("Greater than") -> - Greater than -> GREATER_THAN = 'Greater than' GREATER_THAN_B("Greater than >") -> - Greater than > -> GREATER_THAN_GT_ = 'Greater than >' GREATER_THAN_C("Greater than &gt") -> - Greater than &gt -> GREATER_THAN_GT = 'Greater than &gt' GREATER_THAN_D(">") -> - '>' -> _ = '>' GREATER_THAN_E("\\>") -> - \> -> _ = '\>'

[mb21]

Seems like we have the same problem when having an empty string in the json input (which validates):

          "type": {
            "type": "string",
            "enum": [
              "jpeg",
              "svg",
              ""
            ]
          },

[christianvogt]

Encountered the same issue when we have enums with an empty string value.

edit: used x-enum-varnames to fix this