-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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] Include external fragments in generated output #10269
Comments
This option allows you to include external fragments in the generated code. Closes dotansimha#10269.
This option allows you to include external fragments in the generated code. Closes dotansimha#10269.
Hi @adapap , Please create a minimal reproduction available on GitHub, Stackblitz or CodeSandbox. |
Hey @eddeee888, Here's a Sandbox that should be a minimal repro. I'd like the generated It looks like in the latest versions of the typescript-operations plugin my proposed fix doesn't seem to work because the underlying visitor used is different (it's not ClientSideBaseVisitor). |
Hi @adapap , By default, codegen doesn't import the fragment, but it includes and flattens the fragments in the generated template. From your example, I can see that given these GraphQL documents: query user {
user(id: 1) {
...ExternalUser
}
}
fragment ExternalUser on User {
id
username
email
} The generated type is: export type UserQuery = {
__typename?: 'Query',
user: {
__typename?: 'User',
/* Fields below come from ExternalUser */
id: string,
username: string,
email: string
}
}; So, the final generated type is correct IMO. If this is not correct, could you please let me know why and what you expect instead please? |
@eddeee888 Yes, the default behavior makes sense and the codegen behavior is correct! For our specific use case, we'd like to (redundantly) have the fragment be generated as an auxillary type in the output. In the example, if the fragment is defined in the same file as the query, the codegen will output a separate type for the query and fragment itself. We're interested in opting-in to this behavior when the fragment is imported from another file. This should be possible by processing the external fragments in the same way as fragments defined within the document. This is technically possible with the I've updated the sandbox to include another document with a local fragment and you can see the difference in the generated output. |
Hey @eddeee888, did you have a chance to review the above? Would like to brainstorm possible approaches here, and can explore putting up a PR depending on what approach sounds reasonable to you. I think with the above PR that I proposed, my team can write a custom plugin to extract the types for external fragments even if the |
Hi @adapap , Sorry, I had a small break last week. I'm trying to understand whether this would be used by others in the communities too. |
Hi @eddeee888, welcome back! The reasons for us using this are two-fold:
We're favoring redundancy here to keep the scope of imports smaller in the component implementations. We already have this expectation for enums and input objects defined within a query so we don't have to write things like |
This is released as alpha Thank you so much for implementing this fix! 🚀 |
@adapap please help the alpha release if you have some time 🙏 |
Experimented with this, but unfortunately in my specific use case it didn't end up solving the problem because I was able to work around the issue by manually calling Since this workaround works for me, and since it's unclear to me how to implement this configuration option with the |
I see, thanks for teh detailed explanation. Really appreciate you working with me on this journey ! 🙏 |
Is your feature request related to a problem? Please describe.
Hello! I am in the process of migrating a codebase away from Apollo Codegen (which has been deprecated for some time now) to @graphql-codegen/cli. One compatibility issue that I'm trying to address is that external fragments are not included in the output. We have GraphQL files with usages like this:
This does not include
ExternalFragment
in the generated output, but we would like to include this despite the redundancy of being able to import from the external file directly using thenear-operation-file
preset withtypescript-operations
.Describe the solution you'd like
The relevant code is here. I'd like to have a configuration option in the
typescript-operations
plugin calledincludeExternalFragments
which simply ignores this line.Describe alternatives you've considered
While the
extractAllFieldsToTypes
option does generate fragments, it also generates all types for other fields which we are not at this point interested in.Any additional important details?
No response
The text was updated successfully, but these errors were encountered: