Releases: elastic/elasticsearch-js
v9.0.0
v8.18.0
v9.0.0-alpha.5
Changes from 9.0.0-alpha.4:
Serverless client merged back in
The @elastic/elasticsearch-serverless client is being deprecated, and its functionality has been merged back into this client. This should have zero impact on the way the client works, except that a new serverMode option has been added. When it's explicitly set to "serverless" by a user, a few default settings and behaviors are changed:
- turns off sniffing and ignores any sniffing-related options
- ignores all nodes passed in config except the first one, and ignores any node filtering and selecting options
- enables compression and
TLSv1_2_method(same as when configured for Elastic Cloud) - adds an
elastic-api-versionHTTP header to all requests - uses
CloudConnectionPoolby default instead ofWeightedConnectionPool - turns off vendored
content-typeandacceptheaders in favor or standard MIME types
Docstrings for types that differ between stack and serverless have also been updated to indicate when that is the case.
v9.0.0-alpha.4
Changes from v9.0.0-alpha.3:
Parameter collation
Each API function's logic for deciding where in the request to put each passed parameter is now as follows:
- if recognized as a
bodyparam from the spec, put it in the JSON body - if recognized as a
pathparam, put it in the URL path - if recognized as a
queryparam or a "common" query param (e.g.pretty,error_trace), put it in the querystring - if not recognized and this API accepts a JSON body, put it in the JSON body
- if not recognized and this API does not accept a JSON body, put it in the querystring
The first two steps are identical to 8.x and prior 9.0.0 alpha releases. The last three steps replace the logic that put all unrecognized params in the querystring.
Parameter name list management
Each API function now only instantiates its arrays of accepted body/path/query param names once per client instance rather than during every function call, by moving the array values up to the constructor or module level, depending on which is available. Hopefully this introduces a small performance/memory improvement.
v8.17.1
v8.16.4
v9.0.0-alpha.3
Changes from 9.0.0-alpha.2:
- The default 30-second timeout on all HTTP requests sent to Elasticsearch has been dropped in favor of having no timeout set at all. The previous behavior still works as it did when setting the
requestTimeoutvalue. #2573
v9.0.0-alpha.2
Changes from 9.0.0-alpha.1:
- Rather than fully dropping the
bodyparameter, each HTTP request type includes optionalbodyandquerystringparameters that will add any provided values to the body and querystring, respectively. They have permissive{ [key: string]: any }types (basicallyRecord<string, any>), except they do not allow any of properties that should been in the root of the object.