dotansimha/graphql-code-generator

[TypeScript] Inline fragment type names conflict with fragment definition type names

Open

#5.463 aberto em 28 de jan. de 2021

Ver no GitHub
 (1 comment) (0 reactions) (0 assignees)TypeScript (1.295 forks)batch import
corehelp wantedpluginsstage/1-reproduction

Métricas do repositório

Stars
 (10.341 stars)
Métricas de merge de PR
 (Mesclagem média 22d 9h) (53 fundiu PRs em 30d)

Description

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?

Guia do colaborador