Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
4 tasks done
Bisdow opened this issue Jan 2, 2024 · 2 comments
Closed
4 tasks done

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

Bisdow opened this issue Jan 2, 2024 · 2 comments

Comments

@Bisdow
Copy link

Bisdow commented Jan 2, 2024

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

@Bisdow Bisdow added the Status: Review Needed Request for review comments label Jan 2, 2024
@kazupon kazupon added the typescript label Jan 4, 2024 — with Volta.net
Copy link
Member

kazupon commented Jan 4, 2024

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!

@kazupon kazupon removed the Status: Review Needed Request for review comments label Jan 4, 2024 — with Volta.net
@kazupon kazupon closed this as not planned Won't fix, can't repro, duplicate, stale Jan 4, 2024
@Bisdow
Copy link
Author

Bisdow commented Jan 4, 2024

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. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants