AdditionalSearchParameters type behavior
Hi I recently upgraded the following packages in my project:
"typesense": "^2.0.3",
"typesense-instantsearch-adapter": "^2.9.0"
Previously, I was using:
"typesense": "^1.4.4",
"typesense-instantsearch-adapter": "^2.8.0"
In version 2.8.0, when passing invalid values to additionalSearchParameters, TypeScript would throw type errors — for example, if I did:
additionalSearchParameters: {
group_limit: 'lol', // ❌ TS error
}
This was helpful for catching mistakes early.
However, in 2.9.0, this type-checking seems to be relaxed — now TypeScript doesn't complain about incorrect values in additionalSearchParameters, even though they may still cause a runtime RequestMalformed error from the API.
Could you clarify:
Was this relaxed type behavior intentional?
Is there a recommended way to enforce strict typing on additionalSearchParameters in the latest version?
Another reason I updated the library is related to the infix parameter. In v2.8.0, the type expects an array:
infix: ['off', 'off', 'always'] // ✅ TS accepts this
But when using this with a Typesense cluster running v28, it results in an error:
RequestMalformed: Request failed with HTTP code 400 | Server said: One or more search parameters are malformed.
After reviewing the documentation, I discovered that the server expects a comma-separated string like:
infix: 'off, off, always' // ✅ works at runtime
But then I had to bypass TypeScript like this:
infix: 'off, off, always' as any
Could you please clarify:
What is the correct type for infix expected by the server in v28?
Should the types in the adapter match this format (i.e., allow a string)?
Typesense Server only accepts a comma-separated string value for infix:
infix: 'off, off, always'
But in typesense-js we started allowing an array version of comma-separated parameters and do the conversion from array to a CSV string before sending it to the server.
@tharropoulos We should definitely allow for a string in the types as well, because that's what Typesense Server expects.
The array data type is a convenience method just in the JS library.
The issue is in the main JS library. We're only allowing either an array of Infix operations or a single one. I'll implement a fix for this on the Typesense JS repo and then update the dependency here.
Thank you for the quick response regarding the infix parameter!
I also wanted to ask about the typing for additionalSearchParameters in v2.9.0. Previously (in v2.8.0), TypeScript would correctly flag invalid values - for example, passing a string like "lol" for group_limit would trigger a type error since it expects a number.
I also wanted to ask about the typing for additionalSearchParameters in v2.9.0. Previously (in v2.8.0), TypeScript would correctly flag invalid values - for example, passing a string like "lol" for group_limit would trigger a type error since it expects a number.
It now doesn't?
I've made a PR for this on the main repo.
I also wanted to ask about the typing for additionalSearchParameters in v2.9.0. Previously (in v2.8.0), TypeScript would correctly flag invalid values - for example, passing a string like "lol" for group_limit would trigger a type error since it expects a number.
It now doesn't?
In the latest version it works like this:
In the older version it worked like this:
Thanks for reporting this, I've addressed this in #243
I've integrated both PRs (#290 and #243) into my project. TypeScript now correctly validates additionalSearchParameters (like group_limit and sort_by), showing errors for invalid types as expected, but I'm still getting TypeScript errors when using the correct comma-separated string format.
Can you share the error? Should be on v.2.9.1-2
Type '"off, off, always"' is not assignable to type 'OperationMode | OperationMode[] | { error: "Invalid operation mode"; value: string; } | undefined'.ts(2322)
(property) infix?: OperationMode | OperationMode[] | {
error: "Invalid operation mode";
value: string;
} | undefined