Use peer dependencies

The discussion of peer dependencies in #129 got me thinking - what do you think about moving react-i18next, i18next (and perhaps other associated i18next packages), and react to dev dependencies and also including them as peer dependencies (much like the next-i18next package does with i18next and react)? It would help communicate minimum compatible versions of each package and would help us avoid yarn warnings like this one:

'warning “next-i18next > react-i18next@9.0.9” has incorrect peer dependency “i18next@>= 14.0.1”.

In this case, our package.json specifies i18next@^13.1.3, but the next-i18next package.json specifies react-i18next@^9.0.4 (currently v9.0.9) which has a peer dependency of i18next@^14.0.1. I think that we’re going to constantly run into these incorrect peer dependency warnings unless we just specify next-i18next as a peer dependency (with the lowest compatible version number). Then users could install our package alongside the other peer dependencies when they want to use next-i18next.

We would still have to keep the dev dependencies up to date, but the warnings would not show up for our users and I think it communicates more effectively that these packages are to be installed with our package and we only need to install them in our package if we’re doing some sort of development (e.g. our e2e tests).

[isaachinman]

@kachkaev Yes, I think I agree with you. The only true peer deps here are next and react.

@capellini To answer your question, I want next-i18next to be a replace for both react-i18next and i18next. In general there is quite a lot of confusion and lack of knowledge in the dev community about i18next and its ecosystem, and this package attempts to hide a lot of that away and allow users to just think about their JSON namespaces and get on with it.

However, for advanced use cases, I believe that users may still need to use i18next

What cases? If there are situations where users need to install and import i18next directly, that probably means we’ve failed to expose some part of the API.

[capellini]

Understood. It makes much more sense now that I see the example implementation. Thanks.