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

near-operation-file-preset: Cannot use flattenGeneratedTypes w/ fragments across files #112

Open
arcanis opened this issue Nov 15, 2020 · 6 comments

Comments

@arcanis
Copy link

arcanis commented Nov 15, 2020

Describe the bug
Using the flattenGeneratedTypes option (required to workaround dotansimha/graphql-code-generator#4212) causes GraphQL to fail to locate fragments when using near-operation-file-preset and the fragments are located in other files (regardless whether the queries are written in .graphql or .ts files w/ imports).

Similar to dotansimha/graphql-code-generator#528

To Reproduce
https://codesandbox.io/s/empty-fast-xl915?file=/codegen.yml

Expected behavior
Should compile fine with or without flattenGeneratedTypes.

Environment:
n/a

@arcanis arcanis changed the title flattenGeneratedTypes w/ fragments across files near-operation-file-preset: Cannot use flattenGeneratedTypes w/ fragments across files Nov 15, 2020
@dotansimha
Copy link
Owner

The actual issue here is the fact that we are applying the flattenGeneratedTypes on the level of the plugin, after the preset has been executed and all operations has been splitted to separate output files.
That means, that we get a file for the fragment, and a file for the operation, but the operation needs to flatten the selection set and remove the fragment completely. Some kind of a race condition.

To get this solved, we need to apply the optimizeDocuments method on the level of the loaders in graphql-tools, and allow to pass the flag there - this way it will allow us to optimize operations before codegen preset gets it.

@ardatan fyi :)

@fubhy
Copy link

fubhy commented Jul 14, 2021

We are also running into this (dotansimha/graphql-code-generator#6199).

The bug label was removed a few days ago. Is there a solution for how this can be fixed through config or why is this not considered a bug?

@jdmoody
Copy link

jdmoody commented Sep 15, 2021

I'm continuing to run into errors due to this issue and I'd love to see a fix for it 🙂

I'm in the process of incrementally migrating from Apollo code-generated typedefs to graphql-code-generator typedefs and this is the last issue that prevents full interoperability between the two.

To get this solved, we need to apply the optimizeDocuments method on the level of the loaders in graphql-tools, and allow to pass the flag there - this way it will allow us to optimize operations before codegen preset gets it.

I tried digging into the graphql-tools code to accomplish this, but I couldn't get it to work. It was a while ago and I was just hacking around in the built lib within my node_modules so I don't remember exactly what I tried 😅 I remember getting some errors about unknown or unrecognized fragments, I think 🤔

@dotansimha, @ardatan, are there any additional details or files you could point me to where the change should be made? I'd be happy to give it another try in a more rigorous way.

Thanks 🙏🏻

@vladnkolesnikov
Copy link

Up, have the same issue

@endophasie
Copy link

Yes, this is not solved yet

@dotansimha dotansimha transferred this issue from dotansimha/graphql-code-generator Feb 5, 2023
@Minho-Lee
Copy link

Still having this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants