Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

graphql-modules-preset doesn't obey enumsAsTypes and doesn't generate per-module Resolvers types for enum internal values #6023

Open
Tracked by #8296 ...
darkbasic opened this issue May 19, 2021 · 5 comments
Labels
core Related to codegen core/cli kind/question Improvements or additions to documentation stage/0-issue-prerequisites Needs more information before we can start working on it

Comments

@darkbasic
Copy link
Contributor

Describe the bug
When using the graphql-modules preset it always generates enum as TypeScript type instead of enum, even if you specify enumsAsTypes: false (which is the default anyway).
Also it doesn't generate per-module Resolvers types for enum internal values (it does in the complete schema types).

To Reproduce
This is the repro: https://github.com/darkbasic/gqlmodules-codegen-enumastypes-repro
This is the codesandbox url: https://codesandbox.io/s/github/darkbasic/gqlmodules-codegen-enumastypes-repro

About the enums Resolvers types as you can see they get generated in the complete schema types: https://github.com/darkbasic/gqlmodules-codegen-enumastypes-repro/blob/master/src/types/graphql.ts#L133
While they don't in the per-module schema types:
https://github.com/darkbasic/gqlmodules-codegen-enumastypes-repro/blob/master/src/modules/A/types/module-types.ts#L19
https://github.com/darkbasic/gqlmodules-codegen-enumastypes-repro/blob/master/src/modules/B/types/module-types.ts
Module B doesn't even have a Resolvers type because I didn't add a dummy Query to it.

About the enumsAsTypes issue just look here: https://github.com/darkbasic/gqlmodules-codegen-enumastypes-repro/blob/master/src/types/graphql.ts#L21
As you can see it clearly doesn't obey enumsAsTypes: false. If you comment out the graphql-modules preset it will work as expected.

@dotansimha
Copy link
Owner

Hi @darkbasic ❤️

The reason we set enumsAsTypes: true as hardcoded is that we couldn't really allow extensions of enums in TS :(

If the initial GraphQL enum is defined in one module, and extended in another module, we can't access the shared enum and just extend it or add more values to it. If we are using enum as types, we are able to easily extend it and use it in different modules.

Maybe I'm missing something here, but do you think this can be solved in a different way?

@dotansimha dotansimha added kind/question Improvements or additions to documentation stage/0-issue-prerequisites Needs more information before we can start working on it labels Jun 20, 2021
@jjangga0214
Copy link

jjangga0214 commented Sep 20, 2021

@dotansimha

If the initial GraphQL enum is defined in one module, and extended in another module, we can't access the shared enum and just extend it or add more values to it. If we are using enum as types, we are able to easily extend it and use it in different modules.

Maybe I'm missing something here, but do you think this can be solved in a different way?

My idea, if I understood your explanation correctly, is declaring an enum with every possible value, instead of extending it. So this is basically the opposite of extending.

By checking every *.graphql target files, graphql-code-generator can know values the final enum would likely have, so we might be able to create an enum in that way.

@jaredgorski
Copy link

jaredgorski commented Feb 15, 2022

@dotansimha,

Are there any plans to fix this (specifically, per-module resolver types with enums)? I think this issue is actually rather problematic since most any reasonably useful project will use enums and most any large project would likely find graphql-modules-preset useful were it not for this issue. I'm finding myself removing the preset just because I want to define my enums in my module resolvers, but then I lose module-specific types.

Would love to know about any updates on this front. Thanks!

@ardatan
Copy link
Collaborator

ardatan commented Feb 16, 2022

You're always feel free to create a PR :)

@jaredgorski
Copy link

@ardatan 😅 Well hey I just might, got a few things on my plate right now but let me take a deeper look when I get a breath.

@charlypoly charlypoly added the core Related to codegen core/cli label Nov 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Related to codegen core/cli kind/question Improvements or additions to documentation stage/0-issue-prerequisites Needs more information before we can start working on it
Projects
None yet
Development

No branches or pull requests

6 participants