[Snyk] Upgrade @elastic/elasticsearch from 8.13.1 to 9.0.0#7
Open
Dustin4444 wants to merge 1 commit intomainfrom
Open
[Snyk] Upgrade @elastic/elasticsearch from 8.13.1 to 9.0.0#7Dustin4444 wants to merge 1 commit intomainfrom
Dustin4444 wants to merge 1 commit intomainfrom
Conversation
Snyk has created this PR to upgrade @elastic/elasticsearch from 8.13.1 to 9.0.0. See this package in npm: @elastic/elasticsearch See this project in Snyk: https://app.snyk.io/org/dustin4444/project/f27110ea-097b-4515-af2d-df570d85d86c?utm_source=github&utm_medium=referral&page=upgrade-pr
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Snyk has created this PR to upgrade @elastic/elasticsearch from 8.13.1 to 9.0.0.
ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.
The recommended version is 22 versions ahead of your current version.
The recommended version was released a month ago.
Release notes
Package name: @elastic/elasticsearch
-
9.0.0 - 2025-04-15
-
9.0.0-alpha.5 - 2025-04-04
- 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
- adds an
- uses
- turns off vendored
-
9.0.0-alpha.4 - 2025-02-26
- if recognized as a
- if recognized as a
- if recognized as a
- 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
-
9.0.0-alpha.3 - 2025-01-30
- 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
-
9.0.0-alpha.2 - 2025-01-28
- Rather than fully dropping the
-
9.0.0-alpha.1 - 2024-12-05
- Drops support for the
-
8.18.2 - 2025-04-25
-
8.18.1 - 2025-04-21
-
8.18.0 - 2025-04-16
-
8.17.1 - 2025-02-24
-
8.17.0 - 2024-12-12
-
8.16.4 - 2025-02-24
-
8.16.3 - 2024-12-12
-
8.16.2 - 2024-11-21
-
8.16.1 - 2024-11-18
-
8.16.0 - 2024-11-14
-
8.15.3 - 2024-11-21
-
8.15.2 - 2024-11-11
-
8.15.1 - 2024-10-15
-
8.15.0 - 2024-08-12
-
8.14.1 - 2024-08-12
-
8.14.0 - 2024-06-17
-
8.13.1 - 2024-04-09
from @elastic/elasticsearch GitHub release notesChanges from 9.0.0-alpha.4:
Serverless client merged back in
The
@ elastic/elasticsearch-serverlessclient 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 newserverModeoption has been added. When it's explicitly set to"serverless"by a user, a few default settings and behaviors are changed:TLSv1_2_method(same as when configured for Elastic Cloud)elastic-api-versionHTTP header to all requestsCloudConnectionPoolby default instead ofWeightedConnectionPoolcontent-typeandacceptheaders in favor or standard MIME typesDocstrings for types that differ between stack and serverless have also been updated to indicate when that is the case.
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:
bodyparam from the spec, put it in the JSON bodypathparam, put it in the URL pathqueryparam or a "common" query param (e.g.pretty,error_trace), put it in the querystringThe 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.
Changes from 9.0.0-alpha.2:
requestTimeoutvalue. #2573Changes from 9.0.0-alpha.1:
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.This is a 9.0.0 pre-release alpha. Changes may not be stable.
Breaking changes
bodyparameter from all API callsChangelog
Changelog
Changelog
Changelog
Changelog
Important
Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information: