React-i18next: TS throw `Type instantiation is excessively deep and possibly infinite` when there are loads of keys

[jigsawye]

🐛 Bug Report

I have a locale resource which has over than 2500 keys.
After I followed #1193 to set correct types of my project, the errors just happened.

To Reproduce

Expected behavior

No errors

Your Environment

• runtime version: node v12.19
• react-i18next version: 11.8.0
• i18next version: 19.8.4
• os: Mac

[jamuhl]

@pedrodurek you got an idea?

[DCzajkowski]

Isn't this caused by a namespace? I believe namespaces are not supported by type checking currently — I may be wrong though 🙂

[pedrodurek]

Hey @DCzajkowski, actually it does. It supports all cases, single, multiple and no namespace passed. And without augmentation the Resources type, it should work as before in the v11.7.4. So this feature which types all keys and return type of t function is optional.

[DCzajkowski]

Hey @DCzajkowski, actually it does. It supports all cases, single, multiple and no namespace passed.

Good to know namespaces are supported, thanks!

without augmentation the Resources type, it should work as before in the v11.7.4. So this feature which types all keys and return type of t function is optional.

Hm, it didn't work for me. Without type augmentation I was getting type errors for keys :/ I can give you more information, but I don't have time at this moment. Let me know 😉

[pedrodurek]

Hey @jigsawye, we've performed tests with more them 5k keys and it worked perfectly, so 2.5k keys shouldn't be a problem. Could you provide some extra info so we can test the closest scenario that you have there?

1 - Do you know approximately how deep the keys are?
2 - Under your keys, do you have cases where you have arrays inside other arrays, like this?

{
  title: 'x'
  list: [['x', 'y'], ['x', 'y'], ['x', 'y']],
  list2: [{
    subList: [{
      title: 'x'
    }]
  }]
}

3 - How many namespaces do you have?

We're working on the documentation for these new types. So it'd be great to know whether there is a limitation or not. If there is, our idea is to report those limitations to the Typescript team and add that to the documentation.

[pedrodurek]

Hey @DCzajkowski, even using the last version v11.8.3? If so, could you post the error here?

[DCzajkowski]

@pedrodurek Thanks for letting me know. I have just upgraded to v11.8.3 and there are no breaking changes anymore, yay!

Just FYI: the initial error I was getting was not caused by type checking on keys, but on our usage of the WithTranslation type. In 11.8.0 it was expecting and argument <N>, which wasn't provided in our case. It was a long day, sorry for causing confusion 🤭😅

[jigsawye]

Hi @pedrodurek, thank you for your quick response.

The Resources type is like:

export = LocaleResource;
declare const LocaleResource: {
    ns1: {
        key1: string;
        key2: string;
        key3: string;
// ...

I have 48 namespaces. And there are just loads of keys under every namespaces, no array or object.

Actually I’ve already reproduced the error on CodeSandbox.
Please have a look. Thanks!

[pedrodurek]

Hey @jigsawye, thanks for your help. The bug isn't related to the number of keys, but more with the number of namespaces. It seems to be a typescript limitation/bug. We can see on the examples below, that with 22 namespaces it doesn't throw any error, but from 23 it does. The type is inferred properly and there are no compilation time issues though, it's just a warning.

• 22 namespaces
• 23 namespaces

They have an opened issue regarding that, and I posted my examples there. While they investigate it, I'll try to find a way to handle that on our end. All help is welcome! I'll keep you posted.

Unfortunately, typescript doesn't provide a way to suppress this warning via tsconfig (only via @ts-ignore). In the meantime, I'd advise you to wait a bit longer to use this feature (which is optional if you don't augment the Resources type) until we sort that out (for a large number of namespaces). This will be on the documentation as a limitation (for now).

[pedrodurek]

Hey @jigsawye, can you check if you're still getting the warning on the version 11.8.4?

[jigsawye]

@pedrodurek Thanks for your help. The type checking works fine now!

But I have another question.
It's about calling useTranslation with 1 namespace, using a string instead of an array.
It looks like the type checking will only pass without namespace: key:

Please have a look thanks 😄

[pedrodurek]

Hi @jigsawye, I'm glad to hear that!
Regarding the other question, actually, the types were designed to work like that to prevent long compilation time, particularly on cases with thousands of keys, which would increase the compilation time drastically. We're gonna add those limitations on the documentation to avoid confusion.
As the main problem was solved, can we close the issue?

[jigsawye]

@pedrodurek Sure! 😄