4 Commits

Include renames

Author	SHA1	Message	Date
3 people	2779b75d0d	fix(node): resolve remaining pnpm audit findings (#4073) ... `pnpm audit` in `nodejs/` reported a number of vulnerable transitive dependencies. Most were resolved by `pnpm audit --fix`, which bumped the affected packages in the lockfile; the `minimumReleaseAgeExclude` additions in `pnpm-workspace.yaml` are its bookkeeping, exempting the specific patched versions from the repository's 24-hour hold on newly published packages. Two findings needed handling by hand, because the vulnerable package could not simply be moved to a newer release in place. `@opentelemetry/sdk-metrics` 1.30.1 pins `@opentelemetry/core` to its own exact version, and the 1.x line is end-of-life, so GHSA-8988-4f7v-96qf (unbounded memory allocation in W3C Baggage propagation) has no fix available on 1.x. This PR moves the dependency to 2.x, which brings in a patched `@opentelemetry/core`. It is a dev-only dependency with a single consumer, `__test__/otel.test.ts`, and the parts of the API that test uses are unchanged between 1.x and 2.x. `@huggingface/transformers` pins `sharp: ^0.33.5`, and no released version of transformers has moved past `^0.34.5` — every version in those ranges inherits the libvips CVEs in GHSA-f88m-g3jw-g9cj, so there is no upstream release to upgrade to. This PR adds a pnpm `overrides` entry pinning sharp to the patched `^0.35.4` line instead. `pnpm audit` now reports no known vulnerabilities. ## Not included The sharp override only applies to this repository's own dependency tree, since pnpm overrides are not published to npm. Anyone installing `@lancedb/lancedb` together with the optional `@huggingface/transformers` still resolves sharp 0.33.5, and will until transformers itself moves to sharp 0.35. Practical exposure there is low: the CVEs require decoding untrusted images, and LanceDB's transformers embedding function is text-only. `nodejs/examples/` is a separate install with its own lockfile and is untouched here. It pins `sharp: "0.33.5"` directly and `pnpm audit` reports 19 findings against it. Bumping sharp there is more involved than it looks, because sharp 0.35 requires Node >= 20.9 while the examples tests run on the Node 18/20 CI matrix, so it is left for separate work. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Xuanwo <github@xuanwo.io>	2026-09-03 07:31:03 +08:00
Will JonesandClaude Opus 4.8	285add40dd	feat: expose Lance metrics via OpenTelemetry in Python and Node (#3609) ... Bridges Lance's internal `metrics`-crate instrumentation (object store request counts, bytes, latency, errors, and throttles) into OpenTelemetry, in both the Python and Node bindings, with a shared adapter in the Rust core. This is the LanceDB counterpart to lance-format/lance#7537. ## Rust core (`rust/lancedb`) Two new, **off-by-default** features: - `metrics` — re-exports the [`metrics`](https://docs.rs/metrics) crate as `lancedb::metrics` and turns on Lance's object-store instrumentation. Install any `metrics`-compatible recorder to collect them. - `metrics-otel` — adds `lancedb::metrics_otel`, a pull-based adapter that installs a process-global recorder aggregating into lock-free cumulative storage and exposes a snapshot/catalog API (`register_metrics_recorder`, `metrics_catalog`, `snapshot_metrics`, `MetricPoint`/`MetricValue`/`MetricKind`/`MetricDescription`). Both bindings build on this. ## Python `lancedb.otel.instrument_lancedb_metrics()` registers each metric as an OpenTelemetry observable instrument on the given (or global) `MeterProvider`. Available via the `otel` extra (`pip install lancedb[otel]`), which pulls in only `opentelemetry-api` — the application supplies and configures the SDK. ## Node `instrumentLanceDbMetrics()` provides the equivalent wiring against `@opentelemetry/api`. This is the only public entry point; the underlying recorder/catalog/snapshot functions stay internal. Because OpenTelemetry has no asynchronous histogram instrument, histograms are exported Prometheus-style as `<name>_bucket` (with an `le` attribute), `<name>_count`, and `<name>_sum`. Only `_sum` carries the histogram's unit; `_bucket` and `_count` observe cumulative counts and are unitless. The adapter is enabled by default in the Python and Node builds, and off by default in the Rust crate. ## Notes - Requires Lance ≥ `v9.0.0-beta.19`, which ships the object-store metrics APIs (upstream lance-format/lance#7537, now merged). `main` is already on beta.19, so this is a single feature commit with no dependency bump. - Tests: 8 Rust unit tests, 3 Python tests, 2 Node tests, all covering the end-to-end object-store-metrics → OpenTelemetry path. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-09 15:36:03 -07:00
nuthalapativarun	9c12fb6437	fix(nodejs): treat NAPI_RS_FORCE_WASI as truthy only when set to 'true' (#3519) ... ## Summary Fixes the `NAPI_RS_FORCE_WASI=false` issue by upgrading `@napi-rs/cli` from `3.5.1` to `3.7.0`. Closes #3267 ## Root Cause In the `native.js` loader generated by `napi build`, the check was: ```js if (!nativeBinding || process.env.NAPI_RS_FORCE_WASI) { ``` In JavaScript, any non-empty string is truthy, so `NAPI_RS_FORCE_WASI=false` (a non-empty string) inadvertently triggered the WASI fallback path. This caused an `ENOENT` error when `lancedb.wasi.cjs` was not present. ## Fix `@napi-rs/cli@3.7.0` ([napi-rs/napi-rs#3236](https://github.com/napi-rs/napi-rs/pull/3236)) introduced a tri-state check in the template that generates `native.js`: **Before (generated by @napi-rs/cli@3.5.1):** ```js if (!nativeBinding || process.env.NAPI_RS_FORCE_WASI) { ``` **After (generated by @napi-rs/cli@3.7.0):** ```js const forceWasi = process.env.NAPI_RS_FORCE_WASI === 'true' || process.env.NAPI_RS_FORCE_WASI === 'error' if (!nativeBinding || forceWasi) { ``` Only the literal string `'true'` (or `'error'` for strict mode) now activates the WASI path. All other values, including `'false'`, `'0'`, or an unset variable, behave as if WASI is not forced. ## Changes - `nodejs/package.json`: bump `@napi-rs/cli` from `3.5.1` to `3.7.0` - `nodejs/package-lock.json` / `nodejs/pnpm-lock.yaml`: update lock files to match The fix is in the upstream napi-rs tool; the generated `native.js` is not committed to this repository and is produced at build time by `napi build`.	2026-06-09 15:59:30 -07:00
Will JonesandClaude Opus 4.7	81617fd3d9	ci(nodejs): switch from npm to pnpm 11 (#3373) ... ## Summary Switch the nodejs bindings and examples package from npm to pnpm 11 to pick up its stronger supply-chain defaults: - `minimumReleaseAge` defaults to 1 day, so newly-published (potentially compromised) versions aren't resolved into installs for at least 24h. - Install lifecycle scripts (`preinstall`/`install`/`postinstall`) are no longer run for arbitrary transitive deps; only an explicit allowlist may run them, and unapproved scripts cause install to fail (`strictDepBuilds: true`). - Audit uses GHSA IDs and `--fix=update` to add patched versions to `minimumReleaseAgeExclude`. This is the same class of protection that would have blunted the recent TanStack/`@uipath`/etc. compromise discussed in the [Aikido write-up](https://www.aikido.dev/blog/mini-shai-hulud-is-back-tanstack-compromised). ## Changes - Replace `nodejs/package-lock.json` and `nodejs/examples/package-lock.json` with `pnpm-lock.yaml`. - Pin pnpm via `packageManager: pnpm@11.1.1` in both `package.json`s. - Add `pnpm-workspace.yaml` with the four build-script packages we actually need: `@biomejs/biome`, `onnxruntime-node`, `protobufjs`, `sharp`. Everything else is blocked from running install scripts. - Update package.json scripts (`npm run X` → `pnpm X`). - Update workflows: `.github/workflows/nodejs.yml`, `.github/workflows/npm-publish.yml`, and `.github/workflows/codex-fix-ci.yml` — install pnpm via `pnpm/action-setup@v4` and switch `setup-node` caches to `pnpm-lock.yaml`. - Refresh `nodejs/AGENTS.md`, `nodejs/CLAUDE.md`, and `nodejs/CONTRIBUTING.md`. `docs/package-lock.json` is **not** touched — out of scope for this PR. ## Test plan - [ ] `Lint` job (lint Rust/TS + examples lint) passes on CI. - [ ] `Linux (NodeJS 18/20)` build+test passes, including the examples test step. - [ ] `macos` build+test passes. - [ ] `NPM Publish` workflow's PR dry-run completes (build matrix + test matrix + dry `npm publish`). - [ ] No new install-script approvals are required at install time. ## Follow-ups - `update_package_lock_run_nodejs.yml` references a composite action path that doesn't exist (`./.github/workflows/update_package_lock_nodejs`); it was already broken pre-PR. We may want to either delete this workflow or rewrite it for pnpm in a follow-up. - Consider migrating `docs/` to pnpm in a separate PR. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-13 11:27:38 -07:00