Graphql-code-generator: Input types that clash with field names are overwritten

Created on 12 Feb 2019  路  3Comments  路  Source: dotansimha/graphql-code-generator

Describe the bug

Input type names that clash with the root query/mutation key are overwritten with the return type, meaning that variables on the component will no longer be typed to the input:

screenshot 2019-02-12 at 20 23 25

To Reproduce

Schema:

##### included just to satisfy the parser
type Query {
  ignore: Boolean
}

schema {
  query: Query
  mutation: Mutation
}
##### /included just to satisfy the parser

input Login {
  email: String!
  password: String!
}

type LoginResult {
  success: Boolean
}

type Mutation {
  login(input: Login!): LoginResult!
}

Document:

mutation LoginMutation($input: Login!) {
  login(input: $input) {
    success
  }
}

Config:

generates:
  client-types.tsx:
    - typescript-common
    - typescript-client
    - typescript-react-apollo

Expected behavior

For the type generated to avoid overwriting previously defined types.

e.g. instead of:

export type Login = { // <-- Note this is just `Login` and not `LoginResult`, due to the `login()` key
    __typename?: "LoginResult";
   success: Maybe<boolean>;
}

... I'd expect it to match either the original return type, or some combination of key + return type

export type LoginResult = { // <-- Same name
    __typename?: "LoginResult";
   success: Maybe<boolean>;
}

... which would then avoid shadowing the Input interface type already defined outside of the LoginMutation namespace:

export interface Login {
  email: string;
  password: string;
}

Schema/Documents

See above

Environment:

  • OS: macOS 10.14.3
  • Codegen: ^0.16.1
  • Node: v11.8.0

Additional context

This is easily solved in the GraphQL server, by ensuring no identifiers clash. However, it's not always feasible to make changes (especially if you don't control the server), so I believe it makes sense for gql-gen to work around it.

This is possibly solved by namingConvention, but I didn't see anything obvious out-the-box to solve it other than deferring to a separate module.

I've seen a number of issues related to naming conventions, so this may well be related to some of them.

Perhaps it makes sense to have some kind of global identifier check. Before outputting a name, a suffix could be added... for example, LoginField in this case, or a numeric increment.

bug plugins waiting-for-release

Most helpful comment

Fixed in the recent refactor :)

All 3 comments

@leebenson thank you for reporting it. It's definitly a bug.
I'm not sure we can address this easily (without breaking changes) because changing the name might effect all users of this template.
We are currently working on re-implementing the TypeScript template from scratch, and it might solve this issue as well (because we no longer need to generate inner interfaces inside namespaces).

Fixed in the recent refactor :)

Fix available in 1.0.0 馃憤

Was this page helpful?
0 / 5 - 0 ratings