aurelia / i18n

A plugin that provides i18n support.
MIT License
93 stars 70 forks source link

importing xhr backend does not compile for typescript #224

Closed dkent600 closed 7 years ago

dkent600 commented 7 years ago

I'm submitting a bug report

Current behavior: The docs say to that to use the xhr loader one must do:

import Backend from 'i18next-xhr-backend'

But when I do this I get:

"Could not find a declaration file for module 'i18next-xhr-backend'. '[...]/node_modules/i18next-xhr-backend/index.js' implicitly has an 'any' type."

I find I can eliminate the compile error by doing:

npm install @types/i18next-xhr-backend --save-dev

Expected/desired behavior:

Should not have had to install the typings to compile this.

I had spent time creating this issue and researching a solution.

zewa666 commented 7 years ago

@dkent600 I'm not sure I get the problem you're describing. The docs section TypeScript support says in the beginning

As for the XHR-Backend you'll be using:

typings install dt~i18next-xhr-backend --save --global

Do you propose to add the install instruction via the scoped types package?

dkent600 commented 7 years ago

@zewa666 Sorry, I missed that documentation, but I still contend that the typings should not be required to compile. They are not required by any other Aurelia packages, and only by a small handful of others. At least, this is true with modern typescript.

Which segues to: Since Typescript 2.0 or 2.1 (I forget which), the typings tool has become unneeded. This makes for a welcome simplification of the tools ecosystem. Thus the command can be npm install @types/i18next-xhr-backend --save-dev.

zewa666 commented 7 years ago

well in order to use a custom type you have to have the type definition. If you don't use the external package i18next-xhr-backend you wont need the typedef and have no compile errors either. This has nothing to do with this plugin, but is just the way how typescript works. So it just happens that most other Aurelia plugins do not have external references and you haven't encountered the issue.

Whether you use typings, scoped type package or manually copy over the file to some location is actually irrelevant, although I agree that the scoped package approach tends to be more used nowadays.

I was hesitant though to propose that solution, since at the time writing the docs for typescript, most packages from i18next weren't distributed via that approach. With typings you are able to reference the DefinitelyTyped repo as well.

dkent600 commented 7 years ago

OK, I concede that you might be right that typings are necessarily required in this case -- seems like this has also been the case for me with bootstrap and jquery. I have always assumed that in those cases the types were required only because the respective modules were not properly defined.

BTW, with respect to the i18next typings, I tried using them and found them incomplete, or at least, I couldn't figure out how to use them. For example, I wanted to reference the Options interface, but i18next didn't export that interface in a way that I could get the compiler to recognize it.

zewa666 commented 7 years ago

Well this is exactly one of those reason why I personally try to stay away from typescript. With all this overload of tooling, complexity and additional tasks for the end user it feels very heavy. So I feel with you ;)

we can't really do anything about any wrong i18next typedefs on our side. Your best bet would be to head over to the i18next github repo, create an issue there describing your problem and getting that fixed. At least you'll get some directions where to look for.

I'll close this for now, if it happens to still be somehow an issue with aurelia i18n we can always reopen the task. Thx for checking into the stuff and I hope you can get those issues sorted out, for the benefit of all other typescript users.