Workarounds for "Type instantiation is excessively deep and possibly infinite.ts(2589)"

[JamisonSavvyWealth]

Hello, I've been experimenting with adopting gql.tada into an existing codebase and loving it so far - however, I've started running into issues with some of our larger queries composed of many layers of nested fragments. Once the number of fragments descending from a root query gets too large, we hit they Typescript "Type instantiation is excessively deep and possibly infinite.ts(2589)" error

Seems this is a common issue with other libraries with complex type inference such as Kysely, though there are suggested workarounds. Was curious if there's any such thing for gql.tada or work-in-progress?

Edit: I just found microsoft/TypeScript#57878, so looks like this is known by the team. Still love to hear if there are any recommended workarounds!

[kitten]

It's hard for me to make any general comments here without knowing what you're doing exactly.

It's a little easier for me to first of all link to all relevant changes that we made already: https://github.com/0no-co/gql.tada/milestone/1?closed=1
The most relevant and recent one though is this: #125

There is a size limit now to all documents, which is basically intentional. With a recent change we discovered that we can make a performance optimisation in type inference. However, the trade-off was that there is a size limit to any document to create. It's however past a size which we would consider reasonable given fragment co-location.

So, if you have a document that's excessively large and the error goes away when you make it shorter, that document is basically past that size limit, which is tied to how the tokenizer scans the document you write.

You shouldn't really be hitting recursion limits in other cases though. If you are this may be an issue we're unaware of.
There's some more threads related to this on our Discord, but most of these issues were addressed in recent releases ❤️

[JamisonSavvyWealth]

This is good context, thank you! I don't think the document that's hitting this issue is too large, but I have a clearer understanding of where to investigate from here. I'll post again if we ever figure it out, but it also looks like #160 may also solve this when implemented.

[JamisonSavvyWealth]

To fully close out this issue: it seems upgrading my version of gql.tada from ^1.4.0 to ^1.5.2 and @0no-co/graphqlsp from ^1.7.0 to ^1.10.1 has resolved the issue.

Additionally, I enabled turbo mode and am a fan already.