The keyPrefix options is not resolved correctly as of 23.7.14

[pvdstel]

💥 Regression Report

The keyPrefix option in react-i18next is not recognized correctly. This is caused by i18next itself though, not the React package.

The line

const { t } = useTranslation('translations', { keyPrefix: 'deep' });

is resolved to type TFunction<"translations", "deep"> in 23.7.13 and earlier, but resolves to TFunction<"translations", KeyPrefix<"translations">> now.

Last working version

Worked up to version: 23.7.13.

Stopped working in version: 23.7.14.

To Reproduce

I've added this zip file containing a repository which reproduces the issue. It only has the TypeScript, i18next, and @types/react dependencies. The package manager is pnpm. Run type-check to see the issue. Line 20 in index.ts should be producing an error.

repro.zip

The relevant section is reproduced here:

const { t } = useTranslation('translations', { keyPrefix: 'deep' });
t('deep.deep');
// @ts-expect-error
t('morning'); // this line should NOT work.

Expected behavior

The type error should not be occurring.

Your Environment

• runtime version: Node 20.
• i18next version: 23.7.14
• os: Windows
• TypeScript: 5.3.3

[adrai]

@Gotos may this have influenced it? #2101

[Gotos]

No, it won't fix this issue. I'm looking into it 🤔

[adrai]

these lines seems to be the issue:
https://github.com/i18next/i18next/blob/master/typescript/t.d.ts#L54-L57
https://github.com/i18next/i18next/blob/master/typescript/t.v4.d.ts#L54-L57

[adrai]

@marcalexiei maybe you have an idea on why this happens?

[adrai]

What is really strange is, this works:

const prefixedT = i18next.getFixedT('en', 'translations', 'deep')
prefixedT('deep.deep');

// @ts-expect-error
prefixedT('morning');

There's only a problem in combination with useTranslation from react-i18next

[adrai]

v23.7.15 should fix this

[Gotos]

Wow, you're super quick with merging my contributions :D

Yeah, I'm not entirely sure why the typing of useTranslation broke with 23.7.14. When trying to write a minimal reproduction example, I did realize that with a function taking the params (ns: NS, options: {prefix: KPrefix}) things would break, but even just changing the params to (ns: NS, prefix: KPrefix) would not lead to this issue.

I'm also not entirely sure why my fix fixed the issue. Potentially the type resolution just... stopped? As I understand it, the type TFunction<"translations", KeyPrefix<"translations">> that was mentioned should have resolved to TFunction<"translations", "deep"> in the example. Again, I'm really not sure why that wasn't resolved further, but I'm not really an expert with the type system, I just enjoy tinkering :D

@pvdstel, let me know if this is actually fixed for you now or if I missed something about your use case.

[pvdstel]

It seems to be working fine now. Thank you all for the fast response! 😄