Allow orphan enums to be included in the schema, e.g. through `orphanTypes`

[Arno Hilke]

Is your feature request related to a problem? Please describe.

With orphanTypes, I can add types to the schema that are otherwise not referenced; however as far as I can tell there is no way to include an enum that is not referenced by another type.

In my case I want to add an enum to my schema to describe error codes. Since errors are otherwise not typed, this enum is not referenced in any of my other types.

Describe the solution you'd like

Allow passing enums into orphanTypes so they are emitted with the generated schema. The same was added to @nestjs/graphql here: nestjs/graphql#1839.

Describe alternatives you've considered

While other APIs are conceivable, I think it makes the most sense to stick with what @nestjs/graphql put forth.

Additional context

N/A

[Michał Lytek]

@ahilke
Orphaned types were introduced as a solution for multi-schema support, which requires to not emit all types collected from registering via decorators.

It's useful for scenarios like federation, were you sometimes have to declare external type you do not explicitly use later in the code.

It's not intended to be used as a mechanism to put some docs or metadata into schema.

While other APIs are conceivable, I think it makes the most sense to stick with what @nestjs/graphql put forth.

The good API is a good designed API. There has to be some concept, some base idea behind it defined.
@nestjs/graphql has copied TypeGraphQL API a few years ago with some internals too, and now due to a lack of vision and experience with GraphQL, all feature requests are just accepted.

I don't have any plans to follow NestJS in that term. I mean not blindly to be 1:1 compatible, of course you're free to report and bring some ideas to discuss and implement 😉

The other story is that enum error codes are not a good error handling solution in GraphQL.
I would recommend the response pattern, where you can easily define what alternative scenarios might happen (like createUser -> User | EmailAlreadyRegistered). You have full documentation in the schema + with switch-case you have nice handling or "errors" in a typesafe way.

[Arno Hilke]

Thanks Michal, I appreciate you sharing your reasoning with me and suggesting an alternative.

I support your decision to keep the API conventional and I see now how my suggestion might encourage misuse. I agree it's important to consider the wider impact and be able to reject suggestions.

Regarding your suggested alternative, I actually did start to adopt returning unions like you say. My biggest problem is that I cannot do this easily for my existing schema as it breaks existing clients, but where I was able to use it, it works indeed well. Admittedly, my suggestion would have been a bit of a crutch, maybe it is better to not have it at all.

Thanks for all your work on this great library, cheers!