aurelia/i18n

importing xhr backend does not compile for typescript

dkent600 opened this issue · 5 comments

I'm submitting a bug report

  • Node Version:
    8.1.2

  • NPM Version:
    5.0.3

  • Library Version:
    1.6.1

  • Language:
    TypeScript 2.3.4

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:

  • What is the expected behavior?

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

  • What is the motivation / use case for changing the behavior?

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

@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?

@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.

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.

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.

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.