Typescript use export default for esm-first approach

[rosskevin]

Rationale

Long history, explanation and rationale in issue #1351. The runtime and pure javascript remains unaffected.

Moving forward

Use the following import styles regardless of the esModuleInterop setting (sample imports of default and named below, choose the one that fits your use case):

• import i18next from 'i18next'
• import {TFunction} from 'i18next'
• import i18next, {TFunction} from 'i18next'

Implications for esModuleInterop: true users

NO CHANGE at all! Yay.

Implications for esModuleInterop: false (default) users

This is a sample change set for someone that uses both a default and a named import. Adjust imports to your use case accordingly as mentioned above.

-`import * as i18next from 'i18next'`
- const {TFunction} = i18next
+ `import i18next, {TFunction} from 'i18next'`

1. jest breaks - it is run with node and there is no esm loading in ts-jest (they recommend running with esModuleInterop) or with @std/esm (open issue about jest support)
2. ts-node breaks under certain settings

These breakages are expected and intended.

• Typescript recommends the use of, and defines the intent of --esModuleInterop being exactly for the purpose of loading legacy commonjs. (Note that i18next provides both commonjs and esm packages)
• As indicated by ts-jest docs, it is expected that if you load commonjs code, you need to use esModuleInterop: true.

It ultimately comes down to this: i18next is just an ecmascript library.

Loading semantics of webpack, node, jest and other tools are not in the purview of this project. This change recognizes that understanding and aligns the typescript types exactly with the source code and we are using an esm-first approach moving forward.

---

I ask that before registering a dissenting comment here, please look at the linked issue, repository with reproductions and all the research I documented over the past eight hours of work. This is a seemingly innocuous change that will affect some typescript users, but it has been thoroughly researched and it is in-line with typescript recommendations.

Closes #1351

[coveralls]

Coverage remained the same at 93.305% when pulling 13b10da on rosskevin:ts-export-default into 7671a5a on i18next:master.

[rosskevin]

@jamuhl this is a typescript-only breaking change. It is your call on what to do with semver here. I can argue for a major or minor bump. If I were persuaded in one direction, on this case it would be major.

I will be following on with PRs for other i18next projects to deal with the ts interop tests/imports.

[jamuhl]

@rosskevin prefer major too...give me a few minutes to publish this.

[jamuhl]

published in i18next@19.0.0