build(deps): bump i18next from 26.3.0 to 26.3.1

[dependabot]

Bumps i18next from 26.3.0 to 26.3.1.

Release notes

Sourced from i18next's releases.

v26.3.1

• fix(types): t() with a keyPrefix no longer pollutes its return type with sibling keys' values. A regression in 26.3.0 — the [Res] extends [never] guards added to KeysBuilderWithReturnObjects / KeysBuilderWithoutReturnObjects turned the builders into deferred conditional types, so KeyPrefix<Ns> stopped resolving to a literal union and keyPrefix inference widened to the whole namespace. Symptom: useTranslation(ns, { keyPrefix: 'a.b' }) then t('title') would resolve to '<a.b>.title' | '<other.path>.title' | ... instead of just the scoped value. Affected every react-i18next user using keyPrefix. Restored to the eager 26.2.0 form. The same-namespace conflict handling from #2434 still works via _DropConflictKeys at the merge layer (in options.d.ts). Thanks @​aaronrosenthal (#2436).

Changelog

Sourced from i18next's changelog.

26.3.1

• fix(types): t() with a keyPrefix no longer pollutes its return type with sibling keys' values. A regression in 26.3.0 — the [Res] extends [never] guards added to KeysBuilderWithReturnObjects / KeysBuilderWithoutReturnObjects turned the builders into deferred conditional types, so KeyPrefix<Ns> stopped resolving to a literal union and keyPrefix inference widened to the whole namespace. Symptom: useTranslation(ns, { keyPrefix: 'a.b' }) then t('title') would resolve to '<a.b>.title' | '<other.path>.title' | ... instead of just the scoped value. Affected every react-i18next user using keyPrefix. Restored to the eager 26.2.0 form. The same-namespace conflict handling from #2434 still works via _DropConflictKeys at the merge layer (in options.d.ts). Thanks @​aaronrosenthal (#2436).

Commits

• 7bdb5d7 26.3.1
• a655e32 changelog: 26.3.1 entry for #2436
• 57ed812 fix(types): keyPrefix no longer pollutes t() return type with sibling keys (#...
• See full diff in compare view