Typescript compiler incredibly slow with larger number of language resource keys with version >=22

[gunters63]

With the update to version 22 we had lots of Typescript errors in our code base (see also #1852), so we followed the recommended approach to include a declaration file as described in https://www.i18next.com/overview/typescript

However, if we follow this, the Typescript compiler gets incredibly slow, instead of a couple of seconds it now takes minutes to type-check our UI project. As we also use ESlint (with Typescript) to automatically fix issues when saving VS-Code got very laggy too.

I guess this has something to do with the quite large number of language resources, we have over 23000 text resources split over three files. Yes, we have our reasons to have so many and most of the language resource keys are dynamically evaluated at runtime.

I suggest to document a workaround for such use-cases. I changed the new type declarations file like this:

// import the original type declarations
import 'i18next';

// import dataAccess from '../../locales/en/data-access.json';
// import languageResources from '../../locales/en/language-resources.json';
// import spsSignals from '../../locales/en/sps-signals.json';

declare module 'i18next' {
  interface CustomTypeOptions {
    defaultNS: 'language-resources';
    resources: {
      'language-resources': Record<string, string>; // typeof languageResources;
      'data-access': Record<string, string>; //  typeof dataAccess;
      'sps-signals': Record<string, string>; // typeof spsSignals;
    };
  }
}

With this change, Typescript is as fast as before.

Basically, this reverts the return type of the t() function to the old behaviour, always returning a string.
One could handle this separately for each name space. Maybe we do this too because by far the most language resources with dynamically evaluated keys live only in one name space.

[gunters63]

One more thing: I am not sure what is a reasonable number of text resources one can use before Typescript slows down considerably. I guess it could do so with already a few thousands. Was this benchmarked/tested already?

[gunters63]

To answer my own question, I found https://github.com/pedrodurek/i18n-type-tests :).

Here some numbers from our project:

language-resources contains about 5000 resource keys (mostly static keys)
sps-signals contains about 18500 resource keys (all will be evaluated at runtime)

timings:

• tsc -noEmit with above workaround: 9s
• tsc -noEmit with language-resources enabled: 36s
• tsc -noEmit with sps-signals enabled: 7m48!!
• tsc -noEmit with both language-resources and sps-signals enabled: 8m42s!!!

Seems performance issues escalate rather quickly after the number of keys reaches 10000.

[pedrodurek]

Thanks @gunters63 for reporting that.
I'll investigate a little further what we can do to improve that, I'll keep you posted!

[riboher]

Hi @pedrodurek, not sure if related to this, I would say it is, but I am too finding some issues in the eslint checking after updating react-i18next to v12.0.0 together with i18next in v22.0.4. Our CI keeps failing over and over with a heap out of memory error. I'd say the package responsible for it is the former, but seeing that this issue was already opened here, I thought it might be related. Unfortunately I cannot offer more information besides the attached image so I'll understand if not much effort can be put into this.

Thank you!

[pedrodurek]

I have some ideas to reduce the compilation time, and will be working on it in the next days

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.