Use exported enums in type fields

[EdiOancea]

Description

The following types get generated from the schema

// This file is auto-generated by @hey-api/openapi-ts

export type OrderBy = {
    field?: 'order_1' | 'order_2';
    field_2?: 'value_1' | 'value_2' | null;
};

export type field = 'order_1' | 'order_2';

The problem is the additional field type, especially considering it's not used within OrderBy. I can only get this to happen when an enum is used directly as one of the properties.

P.S: Love the tool

OpenAPI specification (optional)

{
  "openapi": "3.1.0",
  "info": {
    "version": "0.1.0"
  },
  "components": {
    "schemas": {
      "OrderBy": {
        "properties": {
          "field": {
            "type": "string",
            "enum": [
              "order_1",
              "order_2"
            ]
          },
          "field_2": {
            "anyOf": [
              {
                "type": "string",
                "enum": [
                  "value_1",
                  "value_2"
                ]
              },
              {
                "type": "null"
              }
            ]
          }
        },
        "type": "object"
      }
    }
  }
}

Configuration

openapi-ts -i ./test-openapi.json -o ./src/shared/testCodegen -c fetch --schemas false

System information (optional)

No response

[EdiOancea]

I just realised there might be a related problem. We're using enums here instead of "anyOf" because I thought this would fix the generated union types from being re-sorted. What I mean by that, is that, from time to time

export type OrderBy = {
    field?: 'order_1' | 'order_2';
};

would turn into

export type OrderBy = {
    field?: 'order_2' | 'order_1';
};

which makes inspecting the diffs difficult, not to mention the fact it makes it more difficult to enforce that the codegen is up to date. (i.e. running it again doesn't generate any more diffs)

[mrlubos]

Yep, this is the next step in improving generated enums!

[EdiOancea]

If the enum is named, it currently works very well in the sense that an enum (or union in this case) is generated and then used so that's a case we don't need to worry about. For the other case, I feel like there are 2 ways to go about this, not entirely sure which is the more correct one:

• you can either try to generate a better name for the enum and use it, maybe taking the "parent" model name and concatenating the currently generating enum name, i.e. OrderBy_field in our case, at which point I'd rather make sure the field is named directly
• you can just let the type inlined where it's used, so the only difference would be not generating the field at all

I prefer the 2nd option cause for the first one, there's a workaround. With that said, I assume it makes things more complicated when you have to be able to generate both unions/enums/javascript enums.