Conflicting types with i18next-fs-backend

[2Pacalypse-]

🐛 Bug Report

Both this library and i18next-fs-backend library declare a (different) BackendOptions type for the backend property in the i18next module. See these two links:
https://github.com/i18next/i18next-http-backend/blob/master/index.d.ts#L125-L129
https://github.com/i18next/i18next-fs-backend/blob/master/index.d.ts#L50-L54

I don't know how you expected this to work, but the TypeScript compilation fails as soon as you have both of these libraries installed:

To Reproduce

Install both the i18next-http-backend and i18next-fs-backend libraries and run TypeScript.

Your Environment

• i18next-http-version: 2.0.1
• i18next-fs-version: 2.0.0

[adrai]

@pedrodurek Can you advice?

[adrai]

@2Pacalypse- are you using them together with i18next-chained-backend? => https://github.com/i18next/i18next-chained-backend#typescript

[2Pacalypse-]

No, I use one on the frontend and one on the backend, so they're different configurations (but in the same project).

[adrai]

Have you also tried with skipLibCheck true ?

[adrai]

related: microsoft/TypeScript#33699

[2Pacalypse-]

Have you also tried with skipLibCheck true ?

skipLibCheck ignores the errors in the declaration files so of course it doesn't show the errors then. However, that does nothing for actually fixing the problem and increasing the type safety.

It seems to me like the current system where each backend overwrites the CustomPluginOptions type simply can't work. Even the i18next-chained-backend does it, so I assume I'd see the same issue if I was using it.

related: microsoft/TypeScript#33699

That TypeScript issue might help, but I don't see it being implemented anytime soon, if ever.

My suggestion would be to simply export the BackendOptions type from each backend, and then allowing users to set it as a generic parameter or something to the init function. i18next-chained-backend should also probably use variadic generic types for its options, but that might be a bit more complicated to implement.

[adrai]

My suggestion would be to simply export the BackendOptions type from each backend, and then allowing users to set it as a generic parameter or something to the init function. i18next-chained-backend should also probably use variadic generic types for its options, but that might be a bit more complicated to implement.

sounds reasonable... what do you think @pedrodurek ? @2Pacalypse- would you like to start a PR?

[2Pacalypse-]

I've made the PRs in the repos that I've been using and been able to test (other backends would probably need to be updated as well):
i18next/i18next#1878
#105
i18next/i18next-fs-backend#34

Note that I've only changed the parts that were relevant to my use case. I'm unfamiliar with the whole codebase so I'm not sure if anything else needs to be updated. The usage looks something like this:

Also, I'd like to point out that this is still a pretty bad solution to this problem, imo. I think a proper solution would be to change the API so each plugin/backend has its options defined at the same place they're initialized, instead of having a mix of all options in the init method. Something like this:

i18n
  .use(HttpBackend, /* http backend options */)
  .use(initReactI18next, /* react i18next options */)
  .init({
    // common i18next options
  })

[adrai]

i18next v22.2.0
i18next-http-backend v2.1.0
i18next-fs-backend v2.1.0