Allow support for custom directives on enum values

[Harsh Patel]

Is your feature request related to a problem? Please describe.
I encountered a challenge when I attempted to use type-graphql to generate a schema file with types defined therein and use this schema file in another project, written in Golang. The Golang project utilizes this schema to generate types using gqlgen. The inability of type-graphql to add custom directives to enum or enum values creates a specific problem when sharing an enum between the two projects.

For instance, type-graphql allows the definition of an enum as follows:

enum TestEnum {
  FIELD_A = "fieldA",
  FIELD_B = "fieldB",
}

However, the generated schema lacks the associated string values:

enum TestEnum {
  FIELD_A,
  FIELD_B
}

Because of this, the generated schema makes the resolution of FIELD_A and FIELD_B in Golang problematic, as it lacks the direct means to resolve these fields to their associated string values. This situation is problematic, especially when the Golang service depends on these string values for various logic, including federation logic.

Describe the solution you'd like
I suggest enabling the support for custom directive string in registerEnumType function as a part of valuesConfig. This change will parallel the availability of the @directive decorator available on classes and class fields. Following is the API enhancement that I suggest -

interface DirectiveOptions {
  sdl?: string
}

type EnumValuesConfig<TEnum extends object> = Partial<Record<keyof TEnum, DescriptionOptions & DeprecationOptions & DirectiveOptions>>;

The above enhancement will help in enabling clearer and more versatile enum definitions across diverse projects and technologies.

Importantly, GraphQL schemas already support custom directives; I have implemented this functionality in the Golang project for other enums. Therefore, enabling this support in the schema file generated by type-graphql should be feasible; it's the restriction imposed by the type-graphql wrapper that’s the impediment.

Describe alternatives you've considered
I am currently maintaining enums in both services to work around this limitation. However, this approach is not scalable and is susceptible to inconsistencies when modifications occur in the enums.

Additional context
NA

[Michał Lytek]

The problem with directives for enums or unions is that we need to generate the astNode value which is a hacky workaround.
If you can spend some time and investigate how different enums with directives looks in AST, then we could push this feature forward.

[Carlo Corradini]

Moreover, afaik string enum are not supported in SDL:

GraphQL has a constant literal to represent enum input values. GraphQL string literals must not be accepted as an enum input and instead raise a query error.

Query variable transport serializations which have a different representation for non‐string symbolic values (for example, EDN) should only allow such values as enum input values. Otherwise, for most transport serializations that do not, strings may be interpreted as the enum input value with the same name.

[Michał Lytek]

However, the generated schema lacks the associated string values:

That's by design in GraphQL. Schema represent only public API. While interacting with API, you use the enum member names. The runtime values are internal implementation - some runtime can allow for string, other only for number values, depends on the underlying programming language.