near-operation-file and same fragment names across separate operation files
Describe the bug
First of all thanks a lot for this code generator it helps and simplifies live a lot!
I am using near-operation-file preset to create an isolated types and document-nodes for different modules in the project. Please check the approximate folders structure in example app. The thing is that In both shop and user I have the fragment with the same name (Address) that is used in different fragments (nested fragment) and models must be isolated and fully self contained. But after generating I see that some fragments and document-nodes were imported from shop in user types and document-nodes (in case if there would be also queries and mutations).
If I use the config that is listed below.
It results in user model having imports (same name fragments) of document-nodes from shop model, but those imports are unused. And as I see the document node is invalid, as it has {"kind":"FragmentSpread","name":{"kind":"Name","value":"Address"} inside, but there is no definition of Address fragment listed after. When I set dedupeFragments: false, the definition appears back. I understand that the typed-document-node is a separate package and it could be an issue there, but the type of that fragment was not generated also in user model. Also with parameter inlineFragmentTypes: combine I can clearly see that the type was really imported from shop model in user model. I assume that typed-document-node package relays on some outcome of of previous stages of generation and that is why it does not work well, where the previous stage is generating fragments but not importing them from other module.
(for document-nodes generating I was able to overcome the issue with typed-document-node by applying the parameter documentMode: documentNode, after it all document-nodes has there fragment definitions hardcoded inside the document-node but not imported - which is not actually the best solution, but should work)
Your Example Website or App
https://codesandbox.io/s/near-operation-file-types-issue-yvmqlv?file=/models/user/graphql/user.fragments.graphql
Steps to Reproduce the Bug or Issue
Please check the example application and files generated in both shop and user models
Expected behavior
I expected to see the generated types of nested fragments in the different models separately if fragments were described separately in different files. In example application there is a type AddressFullFragment in shop model generated types and this exact type I would expect to see in user model also. And same idea for document-nodes (if it is applicable to this issue and not the separate one for separate package typed-document-node)
Screenshots or Videos
No response
Platform
- OS: macOS
- NodeJS: 16.14.2
- @graphql-codegen/add: 3.2.1
- @graphql-codegen/cli: 2.11.5
- @graphql-codegen/near-operation-file-preset: 2.4.1
- @graphql-codegen/typed-document-node: 2.3.3
- @graphql-codegen/typescript: 2.7.0
- @graphql-codegen/typescript-operations: 2.5.0
- @graphql-typed-document-node/core: 3.1.1
- graphql: 16.5.0
- typescript: 4.7.4
Codegen Config File
overwrite: true schema: schema.graphql documents: "./models/**/*.graphql" generates: ./types.ts: plugins: - typescript ./: preset: near-operation-file presetConfig: extension: .types.tsx folder: codegen baseTypesPath: ./types.ts plugins: - typescript-operations - typed-document-node config: skipTypename: true dedupeFragments: true useTypeImports: true # documentMode: documentNode # inlineFragmentTypes: combine
Additional context
No response
Spend some time debugging this issue and checking the source code, it is a little bit wired.
Here is what I found:
near-operation-file is responsible for inserting externalFragments, and it does the job right, the problem is on the level higher with data that is passed to near-operation-file. To be exact - with documents, or in @graphql-codegen/cli/bin.js with outputDocuments variable. It has different value 'Generate' stage for the first - task (generating typescript types) and for the second task - generating typescript-operations with typed-document-node.
And if I just remove the first task (with plugin typescript types), assuming that they are already generated, and leave the second task (generating typescript-operations with typed-document-node) - that worked like a charm: got both UserFullFragment and AdressFullFragment in user model in the same file (user.fragments.types.tsx) and shop model still has it's own ShopFullFragment and AdressFullFragment (shop.fragments.types.tsx), it worked for both types and document-nodes.
Firstly I thought that it is connected with parallel tasks processing or with types file writing between tasks (or even parallel work on two tasks) but looks like it is not. Will continue researching. If anyone has an idea why it could happen comments appreciated.