Cannot read/write nested fragments
See original GitHub issueVersions
Versions
- @graphql-codegen/add@3.0.0
- @graphql-codegen/cli@2.0.1
- @graphql-codegen/near-operation-file-preset@2.0.0
- @graphql-codegen/plugin-helpers@2.0.0
- @graphql-codegen/typed-document-node@2.0.0
- @graphql-codegen/typescript@2.0.0
- @graphql-codegen/typescript-graphql-files-modules@2.0.0
- @graphql-codegen/typescript-operations@2.0.1
Describe the bug
In our project, we create a new GraphQL file for each query, mutation, and fragment. Out of that, a types file is generated, including the GraphQL document.
We’re making use of the Apollo write/read fragment feature, in order to store some state in the Apollo cache or simply overwrite some data. For this, we use the document of the fragment from the generated types file.
With the latest update, we get an error, that no fragment was found for a specific name. We looked a bit deeper into that and found out, for fragments that import another fragment, the fragment is not included in the respective document.
fragment Zip on Zip {
zip
}
#import "./zip.fragment.gql"
fragment Address on Address {
street
zip {
...Zip
}
}
import { AddressFragmentDoc } from './address.fragment.gql-types.tsx';
client.writeFragment({
fragment: AddressFragmentDoc,
data: {
// the data
}
})
This causes the following error: Invariant Violation: No fragment named Zip.
Looking into the changes of our current upgrade PR, we can see that for all fragments that all fragment.definitions
assignments to the document got removed, while they been added to the respective query and mutations.
Example:
export const AddressFragmentDoc = {
kind: 'Document',
defintions: [
{
// the current fragment document defintion
}
- ...ZipFragmentDoc.definitions
]
}
It seems, by removing the definitions of the imported fragment we lose the information about the fragment.
Questions
- is this a bug?
- is there any configuration around this issue?
Issue Analytics
- State:
- Created 2 years ago
- Reactions:7
- Comments:6
I’m hitting this as well. Is there a fix in sight?
@johannesbraeunig Can you please provide a reproduction or even better pr with a failing test for this?