opensearch-js
opensearch-js copied to clipboard
[BUG] Built-in `english` analyzer not supported by type definitions
What is the bug?
The docs show an example of configuring an English analyzer like so:
{
"settings": {
"analysis": {
"analyzer": {
"english_analyzer": {
"type": "english",
// ...
}
}
}
}
}
But the type definitions don't seem to reflect that such valid is valid for type:
Type '"english"' is not assignable to type '"custom" | "fingerprint" | "keyword" | "language" | "nori" | "pattern" | "simple" | "standard" | "stop" | "whitespace" | "icu_analyzer" | "kuromoji" | "snowball" | "dutch" | "smartcn" | "cjk" | "phone" | "phone-search"'. ts(2322) _common.analysis.d.ts(76, 3): The expected type comes from property 'type' which is declared here on type 'Analyzer'
How can one reproduce the bug?
import { type API } from "@opensearch-project/opensearch";
const indexConfig: API.Indices_Create_RequestBody = {
settings: {
analysis: {
analyzer: {
english_analyzer: {
type: "english",
// ~~~~ <- type error
// ...
},
},
},
},
}
What is the expected behavior?
"english" should be a valid value for type in the Analyzer union type
What is your host/environment?
macOS 15.3.1 Node.js v22.14.0 TypeScript v5.7.2
Do you have any screenshots?
If applicable, add screenshots to help explain your problem.
Do you have any additional context?
Add any other context about the problem.
Did you mean to use a language analyzer? https://github.com/opensearch-project/opensearch-js/blob/398854273f51271cf0279727e87284aa12d0ac48/api/_types/_common.analysis.d.ts#L301-L308
then type should be 'language' and while language should be 'English'
Did you mean to use a language analyzer? https://github.com/opensearch-project/opensearch-js/blob/398854273f51271cf0279727e87284aa12d0ac48/api/_types/_common.analysis.d.ts#L301-L308
then
typeshould be'language'and whilelanguageshould be'English'
That's my current workaround, but according to the docs it seems that dedicated language analyzer types such as "english" should be supported. The type definitions do support type: "dutch" for example, hinting that they're partial and missing other valid options. Using { type: "language", language: "English" } is longer and much more boilerplate.
I see. Since that type was generated from the this schema in the spec, this is an issue of the spec. I've created an issue there: https://github.com/opensearch-project/opensearch-api-specification/issues/833