TypeScript Type of "Composer.t" seems to be wrong

[Jan]

Reporting a bug?

Using TypeScript 5, i get the following behavior:
I want to translate programmatically, therefore take an instance of the i18n object and access the "t" method on the global attribute
i18nInstance.global.t("translateMe")
This works, but when i run type checks i get the error message

error TS2349: This expression is not  callable.
      Each member of the union type 
      'ComposerTranslation<{}, string, RemoveIndexSignature<{ [x: string]: LocaleMessageValue<VueMessageType>;}>, never, never, never> | VueI18nTranslation<...>'
      has signatures, but none of those signatures are compatible with each other.

Expected behavior

The type check should not return an error and correct types for the "t" method should be provided

Reproduction

See Stackblitz
https://stackblitz.com/edit/vitejs-vite-ua8bjo?file=src%2FLocalisationService.ts
The development preview works (no type checks are run there) but if we run npm run build in the console (which runs also type checks) then we get an error

System Info

TypeScript 5.2.2
Vue-i18n 9.8.0

Screenshot

No response

Additional context

No response

Validations

• Read the Contributing Guidelines
• Read the Documentation
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussions

[kazuya kawaguchi]

Thank you for your reporting!

I've checked your reproduction codes.

You don't need to anotate in _i18n.
Typescript also dynamically recognizes I18n types in the Class.

-  private readonly _i18n: I18n;
+  private readonly _i18n;

Thanks!

[Jan]

Thanks @kazupon for the reply.

It seems a bit confusing to me, to not use the official types, but rely on the TS compiler.

Personally i try to avoid the dynamic TS type recognition for complex types, because quite often a developer (for example me :-) ) makes a mistake and leak out internal functionalities.

Therefore the official types are kind of the API definition. In the best case, type and real implementation is equal. But if not, then personally i would always feel more confident that a developer thought more about the API then about the real implementation.

But just my personal preference.
The t method is officially documented for the Composer in the API reference on the website, therefore the intention to make that method public is clear.

Thanks for your quick support and i wish you a relaxing start in 2024. :-)