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.

[yossefbenhaim]

Hi, first I have to say that I really like gql.tada; It helped me a lot. However, I still have a problem with large TypeScript files when generating types from the GraphQL API. I still haven't found a solution. How to reduce the file because it is composed in one unit in const or bypass the error can anyone help me in this use case?

[kitten]

While it may not seem this way, this issue is kind of unrelated to your problem. As per the comment here, just because you're seeing this error that doesn't mean that it's the same problem unfortunately.
That's because possible causes can come down to what you're doing, whether something's wrong with what you're doing or not following some expected patterns, or whether something else is wrong.
So, as per the earlier comment:

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

Please do open a new GH discussion thread or a Discord thread/message with your problem. You'll find that similar questions have also been asked (most recently on Discord), and in that case it came down to a best practice issue, i.e. a query that was unreasonably big rather than using fragment composition or being split up.

[kitten]

Note on this thread:
See: #167 (reply in thread)
There's several cases where this error may occur:

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

Some are expected, others may not be. It will always come down to your personal setup.

I'm locking this thread to encourage new (personalised) threads to be created, so we can discuss this in relation to each person's problems and to narrow down when and how they're running into this. Please create a thread of your own if you're running into this and give some information on when (and when not) you're seeing the error.

The most common case you'll likely see this (until we have a dedicated warning for this in the TS plugin) is when creating a large query. One that exceeds length limits after which inference in TS slows down.
This can be mitigated by following fragment composition practices

See: https://discord.com/channels/1082378892523864074/1252289704854945895

Quote of the reply from Discord thread above

There's an inherent limit to the size of each GraphQL document due to a limitation and trade-off in how much gql.tada can handle at a time.

TypeScript can only convert so much of a string literal into types before slowing down and becoming less than usable when editing GraphQL queries.
While earlier versions were able to handle larger queries, this made TSServer startup and editing extremely slow past a certain point.

While turbo mode is available the base restriction still exists, which will always affect editing performance. That's why the optimisation that ultimately limits the length of queries is still in place.

We basically determined that in code bases that utilise fragment colocation this doesn't become problematic very often as it's always possible to further split up dependencies per component further.