Allow to disable Input suffix

[pdambrauskas]

📝 Description

We are migrating our schema from a legacy Graphql service to a new on, which is based on graphql-kotlin.
We have some input types that do not have Input suffix and want to migrate those types without breaking the schema.

For this to work in a backwards compatible way , I'm suggesting adding new annotation -@GraphQLSkipInputSuffix,
when it is added on input type - schema generator does not add the suffix

@samuelAndalon

[samuelAndalon]

LGTM, i would just rename the field to skipInputSuffix

[pdambrauskas]

@samuelAndalon, just a thought - maybe it would make more sense to introduce a separate @GraphQLSkipInputSuffix annotation for this use-case?

Maybe having a property GraphQLName makes no sense, since it can be used on queries and output fields?

[samuelAndalon]

that works as well

[pdambrauskas]

Updated. Using dedicated annotation instead of field on name annotation.

[dariuszkuc]

my 2 cents: if you are going with separate annotations I'd probably just call it @GraphQLInputName (vs existing @GraphQLName).

*also you probably should update PR description

[dariuszkuc]

I was just thinking -> if using @GraphQLInputName I think the schema generator should also throw an exception if that type is used for output

[pdambrauskas]

I've added @GraphQLSkipInputSuffix annotation - It makes more sense, because:

• You do not have to specify the Type name, as you would with @GraphQLName - class name will be used
• You can add it only on classes, while @GraphQLName can be added on query fields as well.

@dariuszkuc if we chose to go with @GraphQLInputName, it would look confusing from users perspective, when we also have @GraphQLName - functionality of those two annotations would overlap, since you'd be able to rename the type with both of these.

Alternatively, we could introduce @GraphQLInputType(withSuffix=false), in that case, it would be possible to add input type specific configurations to a single annotation, if it is needed in the future.

[samuelAndalon]

@pdambrauskas PR LGTM, could you please update the 8.x.x docs ? -- as it will be released there first, then we would need to cherry pick it to 7.x.x