This PR introduces breaking changes for many services, particularly those that use shared type libraries. While a manual fix involving the addition of an Input suffix to a Kotlin class could be a solution, it is important to recognize that this would necessitate updating classes across all services within a large organization, which is not practical.
To Reproduce
@GraphQLValidObjectLocations(locations = [GraphQLValidObjectLocations.Locations.INPUT_OBJECT])
data class UriContext(){}
The above code compiles to UriContextInput graphql type, but now it becomes UriContext.
Another potential problem could arise if there is already a UriContext type.
Subgraph schema generates UriContext after graphql-kotlin updates, but shared type lib with older version of graphql-kotlin could still create UriContextInput.
Expected behavior
Ideally revert the PR. If not possible, can we make it configurable?
Library Version Any latest version of 6, 7 and upcoming 8.
Describe the bug https://github.com/ExpediaGroup/graphql-kotlin/pull/1960
This PR introduces breaking changes for many services, particularly those that use shared type libraries. While a manual fix involving the addition of an Input suffix to a Kotlin class could be a solution, it is important to recognize that this would necessitate updating classes across all services within a large organization, which is not practical.
To Reproduce
UriContextInput
graphql type, but now it becomesUriContext
.UriContext
type.UriContext
after graphql-kotlin updates, but shared type lib with older version of graphql-kotlin could still createUriContextInput
.Expected behavior
Ideally revert the PR. If not possible, can we make it configurable?