Good evening, We utilize the `downloadApolloSchema...
# apollo-kotlin
j
Good evening, We utilize the
downloadApolloSchema
Gradle task to get our Schema from our BE and we’ve noticed a change in the behavior for it when upgrading from version 3.7.4 to 3.8.2. When I run the task on 3.8.2 it is adding the built-in scalars (Int, Float, String, etc) as well as some low-level type definitions like
__Directive
and
__Type
. These are not added when I run the command with the 3.7.4 version of the plugin. When these are added they show up as errors in Android Studio stating that we’re redefining existing types. Is there a config in the plugin that we can set to stop getting these?
For context, we are using a
schema.graphqls
file to store our schema. I haven’t tried this with JSON or the sdl extension to see if the behavior is any different
b
Hi! This is a known issue in the GraphQL plugin (which the Apollo plugin depends on), unfortunately there is no fix for now.
j
ah ok, thanks! I was trying to poke around Github for existing issues, but didn’t think to check the Intellij graphql plugin itself.
m
For the record, we do need these directive in the schema for proper query validation. It used to be that we could just assume they were always the same but as GraphQL evolves, not all server have the exact same builtin definitions. One example is
__InputValue.isDeprecated
that was only introduced recently
j
Ah ok, makes sense. I appreciate the info. My plan is to keep those “base” definitions in our schema file and suppress the duplicate type definition inspection. We are very rarely manually editing our schema file in our Android project so I’m not worried about someone actually duplicating a type definition.
m
@Joseph Hawkes-Cates this triggered an interesting discussion in yesterday's GraphQL working group. The spec is currently unclear how to handle those case. Schema driven frameworks must not have them but client tools like Apollo and InteliiJ must have them. If you want the details on the 90min long discussion about evolution of the spec (and client controlled nullability as well), it's available there: https://github.com/graphql/graphql-wg/blob/969c94f83fa1cdeeb9d015d368f2efec0c47aee7/notes/2023/2023-08.md
suppressing the issue is certainly the best short-term actionable solution 👍
j
Nice, thanks! I’m very curious about client controlled nullability as well
nod 1