Remove GQL types from TS type name when extracting fields to types

[BigBrainAFK]

Hello,

I am in the process of (finally) migrating from the apollo cli to graphql-codegen and have arrived at a config that is almost satisfactory.

I have one nit though which is that extractAllFieldsToTypes it generates really long typenames like:

GiftCardCreateMutation_giftCardCreate_GiftCardCreatePayload_userErrors_GiftCardUserError

where GiftCardCreatePayload and GiftCardUserError are not required in the typenames and are just the typename of the fields giftCardCreate and userErrors. (theres also no type that ends on just userErrors)

Any way to disable this behavior?

P.S.: I know of #10561 but wasnt sure if the only option for me is to wait for it to merge into stable in the future.

[eddeee888]

Hi @BigBrainAFK , we are finalising on the stable at the moment (very close now!)

If you'd like to test it out, you could try the versions in this release to see if it fits your purpose?

We are writing migration guide to migrate from Apollo Tooling -> Codegen, including which options to use etc.

[eddeee888]

The issue seems to occur when using a remove schema URL. So just doing schema: "https://shopify.dev/admin-graphql-direct-proxy/2025-04" will result in the input type issue.

Oh nice one! It is indeed related to using remote schema. I'm fixing it here: #10637

I've also updated the demo branch with the latest alpha

I am glad the issue with the Tag types does occur in the example even with a local graphql schema file (see document2.ts).

I think Tag types are supposed to work like that with the config you've shared. Are you seeing issues with how those types are generated? 🙂

[BigBrainAFK]

Oh nice one! It is indeed related to using remote schema. I'm fixing it here: #10637

That is great to hear. Thank you for the speedy fix and reply on this specific issue.

I think Tag types are supposed to work like that with the config you've shared. Are you seeing issues with how those types are generated? 🙂

If I understand correctly (and please correct me if I understand wrong), the mergeFragmentTypes: true, should merge fragments that have the same shape. Turning merging off makes the list of types that comprise TagsAdd_tagsAdd_node and TagsRemove_tagsRemove_node get longer by a lot making me think that I do understand correctly as it does seem to merge types to some degree. With mergeFragmentTypes: true, the TagsAdd_tagsAdd_node type for example is a union of 10 types, however setting it to false it generates 188.

This is also why I put a commend above this option so I don't forget what causes this perceived issue (if I understand the option correctly that is)

EDIT: I made a PR to the demo branch to pull in all the prod GQL files we use and gen closer to how we have it set-up as I noticed another issue with a UserError type which may be related to the same "issue" as the TagsAdd type.

[eddeee888]

Really appreciate your demo PR @BigBrainAFK ! It helps me quickly try different config options.

I believe your understanding is correct. What I could also see here is an issue when inlineFragmentTypes:'combine' and mergeFragmentTypes: true are used together. This is a reported issue here.

For now, I think a fix could be to remove inlineFragmentTypes:'combine'... but you may lose the benefits of type reusability.

I will see if I could include it in the upcoming major version. If not, it'd be a patch after. 🙂

Apart from this, do you see other type issues?

[BigBrainAFK]

So removing inlineFragmentTypes from the config does fix the weird misgenerated type imports but does not resolved the types that dont properly merge. However this at least makes the project buildable for me so it would be an acceptable fix.

The "issue" with the Incremental being exported from each files is also easily fixed by just also exporting type Incremental = unknown after reexporting all files so it is no big issue on our end.

Other than these small nags that dont impact buildability i dont see any more issues with the shopify gen or the other gql clients we have.

Is there a targeted Month/Quarter for the next major version?

[eddeee888]

Thanks for testing the upcoming major version 🙏
I'm aiming to release it early May.