DBCode depends on trino-client@^0.2.7. That package has been renamed and the old name is no longer maintained.
I am a Trino maintainer, and we are working through the downstream consumers of the client. I would have sent a pull request, but the extension source is not in this repository, so the import specifiers are not something I can change from outside. Hence an issue.
The change
-"trino-client": "^0.2.7"
+"@trinodb/trino-js-client": "^0.3.2"
plus the import specifiers wherever the client is used. Versions up to 0.2.9 shipped as the unscoped trino-client; the scoped @trinodb/trino-js-client starts at 0.3.0.
Why it is worth doing
0.3.2 pins axios 1.19.0. trino-client@0.2.7 pins axios 1.13.2, which sits below several advisories:
- prototype pollution, fixed in 1.15.1
- CR/LF header injection in header values
- NO_PROXY loopback bypass, CVE-2026-42043, fixed in 1.16.0
- the form-data floor for GHSA-hmw2-7cc7-3qxx
Since you ship an SBOM in this repo, that nested axios is visible to anyone scanning your releases.
Risk
The declaration files are identical byte for byte between the two packages:
$ npm pack trino-client@0.2.9 && tar xzf trino-client-0.2.9.tgz
$ npm install @trinodb/trino-js-client@0.3.2
$ diff -u package/dist/index.d.ts node_modules/@trinodb/trino-js-client/dist/index.d.ts
$ echo $?
0
Same twenty exports, same shapes. So it is a rename with no API change, and 0.3.2 contains no source changes relative to 0.3.1 — it is a dependency-maintenance release cut precisely so downstream renames carry the axios fixes.
Heads up on the next major
The next major removes axios entirely in favour of native fetch, and will change the error type thrown on a non-2xx response from AxiosError to a typed client error. If you catch AxiosError and read err.response.status anywhere, that is the one thing to watch. Happy to give you a heads up before it ships.
Related work, in case it is useful: trinodb/trino-js-client#970 adds a consumer-side compatibility suite that runs the packed tarball against a real coordinator on every commit.
DBCode depends on
trino-client@^0.2.7. That package has been renamed and the old name is no longer maintained.I am a Trino maintainer, and we are working through the downstream consumers of the client. I would have sent a pull request, but the extension source is not in this repository, so the import specifiers are not something I can change from outside. Hence an issue.
The change
plus the import specifiers wherever the client is used. Versions up to 0.2.9 shipped as the unscoped
trino-client; the scoped@trinodb/trino-js-clientstarts at 0.3.0.Why it is worth doing
0.3.2 pins axios 1.19.0.
trino-client@0.2.7pins axios 1.13.2, which sits below several advisories:Since you ship an SBOM in this repo, that nested axios is visible to anyone scanning your releases.
Risk
The declaration files are identical byte for byte between the two packages:
Same twenty exports, same shapes. So it is a rename with no API change, and 0.3.2 contains no source changes relative to 0.3.1 — it is a dependency-maintenance release cut precisely so downstream renames carry the axios fixes.
Heads up on the next major
The next major removes axios entirely in favour of native
fetch, and will change the error type thrown on a non-2xx response fromAxiosErrorto a typed client error. If you catchAxiosErrorand readerr.response.statusanywhere, that is the one thing to watch. Happy to give you a heads up before it ships.Related work, in case it is useful: trinodb/trino-js-client#970 adds a consumer-side compatibility suite that runs the packed tarball against a real coordinator on every commit.