search

elastic / elastic-transport-js

Transport classes and utilities shared among Node.js Elastic client libraries
Apache License 2.0
4 stars 24 forks source link

All 8.x versions of @elastic/elasticsearch now require node v18 #91

Closed bsherman101 closed 2 months ago

bsherman101 commented 3 months ago

Elasticsearch JS Client v 8.9.0 states that it requires a minimum Node version of v14.

https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/8.9/getting-started-js.html

It's package.json has a dependency of @elastic/transport: "^8.3.2"

This previously built without issue with v16 but now because the transport library is available at v8.5.0, that version is being pulled and the build is complaining about the transport and the undici dependencies requiring v18 but current is v16.

JoshMock commented 2 months ago

There's a lot of overlap here with https://github.com/elastic/elastic-transport-js/issues/90, where we discussed a lot of this at length. But I also understand your point, and can publish patch releases for older 8.x releases to pin to ~8.4.1 to ease some of the pain of this change.

While not ideal, in the meantime you can override the version of @elastic/transport that your projects depend on.

I'll keep this open until I get those patch releases out, hopefully in the next few days.

bsherman101 commented 2 months ago

OK, we decided to go ahead and update our package.json(s) to use the override referenced above until we can migrate to Node 18 or higher.

I do agree with @jsumners-nr comment here https://github.com/elastic/elastic-transport-js/issues/90#issuecomment-2044915788

I don't believe the transport library should be forced to stay within the same versioning paradigm as @elastic/elasticsearch itself. If it requires a major version increment to prevent previous releases from breaking so be it.

JoshMock commented 2 months ago

Historically, transport versions were pinned to the same major/minor version as the client, to ensure that any changes that affect how the client communicates with Elasticsearch via HTTP (or any other protocol) are in alignment with what that version of Elasticsearch supports.

More recently, it's shifted to closer-to-semver versioning, but we are still trying to keep the major version of the transport aligned with the major version of Elasticsearch for the above reasons.

JoshMock commented 2 months ago

The following versions of the client have been published to npm, each of which pins transport to the latest patch version rather than the latest minor, which should resolve this issue.

@jsumners-nr @bsherman101