[TypeScript] Inline fragment type names conflict with fragment definition type names
#5,463 建立於 2021年1月28日
描述
Describe the bug
We use a pattern like this to organize fragments when making selections on union types:
fragment ArticleAuthorUser on User {
id
}
fragment ArticleAuthorGuest on Guest {
id
}
fragment ArticleAuthor on Author {
...ArticleAuthorUser
...ArticleAuthorGuest
}
GraphQL Code Generator creates a type for each fragment spread, and names it based on the parent fragment + the type of the object being spread. In this case, ArticleAuthor_User_Fragment. A second type is generated for the fragment itself: ArticleAuthorUserFragment. Because we've named our fragment following the same conventions as the code generator, these type names will conflict if we set namingConvention: changeCase#pascalCase, resulting in this output:
// From "fragment ArticleAuthorUser on User"
export type ArticleAuthorUserFragment = (
{ __typename?: 'User' }
& Pick<User, 'id'>
);
// From "fragment ArticleAuthor on Author { ...ArticleAuthorUser }"
type ArticleAuthorUserFragment = (
{ __typename?: 'User' }
& ArticleAuthorUserFragment
);
To Reproduce
https://codesandbox.io/s/optimistic-dawn-6f920?file=/types.ts
Expected behavior
It would be useful to be able to customize the naming conventions (suffixes/prefixes/etc.) for inline fragments vs fragment definitions. In the example above, the spread fragment could be dropped from the generated code altogether, but it's not always so simple. The same issue can occur with an inline fragment:
fragment ArticleAuthorUser on User {
id
}
fragment ArticleAuthorGuest on Guest {
id
}
fragment ArticleAuthor on Author {
... on User {
id
}
}
In this case, the types are potentially distinct and both useful, but should have non-conflicting names. Naming the spread type ArticleAuthorUserInlineFragment is one possible solution. Looking through the codebase it actually seems like this may have been the case at one point for some plugins?