Error is not assignable to type 'ReactI18NextChildren | Iterable<ReactI18NextChildren>'

[joaopedrodcf]

🐛 Bug Report

A type issue appears in later releases of react-18next in combination with i18next where the following translations:

{
  "test": "Test",
  "test_2": "Test 2",
  "test_form": {
    "title": "title"
  }
}

It will start generating the following error:
Type '{ title: string; }' is not assignable to type 'ReactI18NextChildren | Iterable'

To Reproduce

I created this code sandbox with a minimal reproduction of the issue:
https://codesandbox.io/p/sandbox/bug-report-react-i18next-7m4mzg

Expected behavior

No typing errors should appear for that use case.

In older version this was not an issue, as can be seen in the same reproduction but older versions https://codesandbox.io/p/sandbox/without-bug-report-react-i18next-gpkgmh

Oldest versions that worked:
"i18next": "23.3.0"
"react-i18next": "13.2.2"

Your Environment

• runtime version: node v20.9.0
• "react-i18next": "13.5.0"
• "i18next": "23.7.8"
• "typescript": "5.3.3"
• "react": "18.2.0"
• os: Mac Sonoma 14.1.2

[adrai]

That's probably because of the nested key test_form...
If you have an idea on how to address this, feel free to try a PR

[adrai]

can be reproduced also in this test case: i18next/i18next@66e3283#diff-97e65d0ee521805ff4ac2d967b61062da8f5543569da4177ceeff689ce4463a3R142

[joaopedrodcf]

Thanks for the quick reply @adrai , currently I don't have any clue why this is happening, I can try to investigate a bit 💯

[joaopedrodcf]

So the temporary solution I found for this problem was fix all the "typescript errors"

{
  "test": "Test",
  "test_2": "Test 2",
  "test_form": {
    "title": "title"
  }
}

{
  "test_form": {
    "label": "Test"
    "label_2": "Test 2"
    "title": "title"
  }
}

Because the problem comes from a nested key containing part of a key, for example "test" exists in "test_form"

[adrai]

@marcalexiei also this one is very strange

[marcalexiei]

Actually this is more an issue of i18next.

I think that the problem is that test key uses an _ which is the default contextSeparator / pluralSeparator.
The key generation got a little messy when creating object with key using the same character of those configuration properties.

I changed the context separator and the type error no longer exists:

I realise that this is more a workaround than a fix.
Probably to allow this kind of keys ParseKeys should be improved.