Making the variable used in fragment fail the code generation if it's not defined in the Query/Mutation

[schinj]

Question

Hi,

Recently, we faced an issue related to missing input param from the mutation while a fragment was using this input param. We didn't notice it until we saw some errors on production.

How to reproduce: Let's say I have a fragment:

fragment TestFragment on MainModel { requiredField: @include(if: $anyCondition) }

Now I am using this fragment in two places, once in a Query and once in a Mutation. The query was updated to include the required param (anyCondition) in the input object but we forgot to add it inside the mutation.

But, this didn't result into any error on compile time. I am not sure if this is supported or not. Could you please help me in answering this? Please let me know if you need any more information.

Edit 1: Platform: iOS Code generation mechanism: Build phase to generate Apollo GraphQL API using run-bundled-codegen.sh.

[calvincestari]

Hi @schinj, I would expect an error on code generation to be returned. Specifically I expect this to get caught by the graphql-js frontend we use as validation of the schema + operations.

Please put together a sample app demonstrating the issue. That will help in tracking it down, thank you.

[schinj]

Thanks for the reply @calvincestari. Is this graphql-js frontend validation being run as part the run-bundled-codegen.sh because that's what we are using currently?

[calvincestari]

Is this graphql-js frontend validation being run as part the run-bundled-codegen.sh because that's what we are using currently?

Ah, well that's a different story. I'd assumed you were on the latest 1.x version but given that you mentioned the run-bundled-codegen.sh script that means you're still on a legacy 0.x version, is that correct?

No, the legacy 0.x versions do not use graphql-js as a compiler and validator. Instead they use a much older CLI for code generation. Unfortunately that old CLI is no longer maintained so if this is a valid bug in that CLI, we'd have to discuss what options there might be.

Have you looked at upgrading to the 1.x version? Are there any blockers that would prevent you from doing so?

[schinj]

I will try to generate the code using the latest CLI. And will confirm if the issue is still there.

Regarding the upgrade to 1.x, I will check if we have any constraints.

[calvincestari]

I recommend taking a read through the 1.0 migration guide first to see how the upgrade may affect your code.

[calvincestari]

Closing this due to inactivity. If this is still an issue for you comment here and we can continue the discussion.