Skip to content

fix(types): expose enableSelector on InitOptions#2431

Merged
adrai merged 1 commit into
i18next:masterfrom
Faithfinder:expose-enableSelector-on-InitOptions
May 14, 2026
Merged

fix(types): expose enableSelector on InitOptions#2431
adrai merged 1 commit into
i18next:masterfrom
Faithfinder:expose-enableSelector-on-InitOptions

Conversation

@Faithfinder

@Faithfinder Faithfinder commented May 14, 2026

Copy link
Copy Markdown
Contributor

Problem

enableSelector is a runtime option — i18next.js reads opts?.enableSelector === 'strict' inside keysFromSelector and applies the namespace-prefix rewrite accordingly — but it isn't declared on InitOptions. As a result, i18n.init({ enableSelector: 'strict' }) fails to typecheck:

Object literal may only specify known properties, and
'enableSelector' does not exist in type 'InitOptions<unknown>'.

CustomTypeOptions['enableSelector'] exists (used for the type-level selector machinery in t.d.ts), but that only configures the compile-time shape. Users still have to pass enableSelector at runtime to actually get strict-mode resolution, and the matching InitOptions field is missing.

Today every project enabling the selector API needs a module augmentation:

declare module "i18next" {
  interface InitOptions {
    enableSelector?: false | true | "optimize" | "strict";
  }
}

Fix

Adds the runtime-side option to InitOptions, slotted next to the other selector-resolution knobs (keySeparator / nsSeparator).

Includes a test/typescript/misc/i18nInstance.test.ts case covering each accepted value:

it('should accept `enableSelector`', () => {
  expectTypeOf(i18next.init).toBeCallableWith({ enableSelector: false });
  expectTypeOf(i18next.init).toBeCallableWith({ enableSelector: true });
  expectTypeOf(i18next.init).toBeCallableWith({ enableSelector: 'optimize' });
  expectTypeOf(i18next.init).toBeCallableWith({ enableSelector: 'strict' });
});
$ npx vitest --config vitest.workspace.typescript.mts run
 Test Files  56 passed | 1 skipped (56)
      Tests  460 passed | 2 todo (462)
Type Errors  no errors

@Faithfinder
fix(types): expose enableSelector on InitOptions
b07cbc0 
`enableSelector` is a runtime option — `i18next.js` reads
`opts?.enableSelector === 'strict'` inside `keysFromSelector` and applies
the namespace-prefix rewrite accordingly — but it isn't declared on
`InitOptions`. So `i18n.init({ enableSelector: 'strict' })` fails to
typecheck with:

  Object literal may only specify known properties, and
  'enableSelector' does not exist in type 'InitOptions<unknown>'.

`CustomTypeOptions['enableSelector']` exists for the type-level selector
machinery, but that only configures the compile-time shape. The runtime
value still has to be passed at init() time, and the matching
InitOptions field was missing.

Adds `enableSelector` to InitOptions alongside `keySeparator` and
`nsSeparator`, and adds an i18nInstance.test.ts case covering each
accepted value (false / true / 'optimize' / 'strict').
@coveralls

coveralls commented May 14, 2026

Copy link
Copy Markdown

Coverage Status

coverage: 94.977%. remained the same — Faithfinder:expose-enableSelector-on-InitOptions into i18next:master

@adrai adrai merged commit 50509e4 into i18next:master May 14, 2026
9 checks passed
adrai added a commit that referenced this pull request May 14, 2026
@adrai
changelog: 26.1.1 entry for #2431
0b9debd
@adrai

adrai commented May 14, 2026

Copy link
Copy Markdown
Member

Shipped in i18next 26.2.0. Thanks @Faithfinder!

@jayaddison

jayaddison commented May 28, 2026

Copy link
Copy Markdown
Contributor

@adrai @Faithfinder do you know whether it'd be straightforward to expand this type coverage (I suppose for all init options) to the jquery-i18next interface?

@adrai

adrai commented May 28, 2026

Copy link
Copy Markdown
Member

@jayaddison good call — turned out to be straightforward. Just shipped it in jquery-i18next@1.3.0 — and hey, 9 years between releases, good to know jquery-i18next still has users! 😄 The package now ships its own TypeScript definitions covering all of jquery-i18next's init options (tName, i18nName, handleName, selectorAttr, targetAttr, optionsAttr, useOptionsAttr, parseDefaultValueFromContent), with the i18next instance typed as i18n. When the default handle names are kept, $.t, $.i18n and $(selector).localize(opts) are added to the jQuery types too. No more manual augmentation needed. 🙂

@jayaddison

jayaddison commented May 28, 2026

Copy link
Copy Markdown
Contributor

That's super impressive - thank you @adrai! I'll update jquery-i18next for my application soon :)

@jayaddison

jayaddison commented May 29, 2026

Copy link
Copy Markdown
Contributor

@adrai that upgrade of jquery-i18next helped me figure out that in fact, I'd placed the enableSelector option in the wrong init options. Typechecking is good! Thanks both :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@Faithfinder @coveralls @adrai @jayaddison