docs: document npm audit workaround#341
Conversation
📝 WalkthroughWalkthroughDocumentation added to Changesnpm audit dependency documentation
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/dependencies.md`:
- Around line 5-19: Update the paragraph to explicitly state that the
`undici@5.29.0` path is what npm consumers may see during their registry
resolution (via `@connectrpc/connect-node@1.7.0`), and that this repo itself
uses `pnpm.overrides` to resolve `undici` to `8.3.0`; reference the symbols
`@connectrpc/connect-node`, `undici@5.29.0`, `undici@8.3.0`, and
`pnpm.overrides` so readers understand the distinction between consuming
projects (npm resolution) and this repository’s pnpm install.
- Around line 39-44: Update docs/dependencies.md to cite upstream migration docs
and specify exact breaking changes: mention that Connect-ES v2 replaces
createPromiseClient with createClient and that Protobuf-ES v2 removes the
PartialMessage export, and replace “transport options changed” with the specific
transport change (e.g., removal of credentials in favor of a fetch override)
with links to the Connect-ES MIGRATING guide and Protobuf-ES v2
release/migration notes; reference the symbols createPromiseClient,
createClient, PartialMessage, and credentials/fetch in the updated text so
readers can correlate to the codebase imports and generated contracts.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 0ba2381f-b982-4f1a-8d2c-85908bbd1fb1
📒 Files selected for processing (1)
docs/dependencies.md
| The npm package depends on `@connectrpc/connect-node` for the gRPC transport used | ||
| to reach the separately installed `libravdbd` service. The current Connect 1.x | ||
| line resolves `@connectrpc/connect-node@1.7.0`, which depends on `undici@5.29.0`. | ||
|
|
||
| Some npm consumers may therefore see `npm audit --omit=dev` report this path: | ||
|
|
||
| ```text | ||
| @xdarkicex/openclaw-memory-libravdb | ||
| └─┬ @connectrpc/connect-node@1.7.0 | ||
| └── undici@5.29.0 | ||
| ``` | ||
|
|
||
| This is not fixed by the `pnpm.overrides` entry in this repository. That override | ||
| only affects this repo's own pnpm install; it does not force npm's dependency | ||
| resolution in a consuming OpenClaw project. |
There was a problem hiding this comment.
Clarify that the undici@5.29.0 path is about npm consumers, not this repo’s pnpm install.
The current package/lockfile context already resolves undici to 8.3.0 via pnpm.overrides, so this reads as if the repo itself still ships the 5.29.0 chain. Please explicitly say this is the registry-resolved path seen by consuming npm projects.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/dependencies.md` around lines 5 - 19, Update the paragraph to explicitly
state that the `undici@5.29.0` path is what npm consumers may see during their
registry resolution (via `@connectrpc/connect-node@1.7.0`), and that this repo
itself uses `pnpm.overrides` to resolve `undici` to `8.3.0`; reference the
symbols `@connectrpc/connect-node`, `undici@5.29.0`, `undici@8.3.0`, and
`pnpm.overrides` so readers understand the distinction between consuming
projects (npm resolution) and this repository’s pnpm install.
| Treat this as a consumer workaround, not the upstream package fix. Moving the | ||
| plugin itself to Connect 2.x is a source migration, not a one-line dependency | ||
| bump: Connect 2 removes the current `createPromiseClient` API, protobuf 2 removes | ||
| the current `PartialMessage` export used by this codebase, and transport options | ||
| changed. The durable upstream fix needs the plugin and generated contracts to | ||
| migrate across that API boundary together. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n '\bcreatePromiseClient\b|\bPartialMessage\b' .Repository: xDarkicex/openclaw-memory-libravdb
Length of output: 3453
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show relevant doc context
sed -n '1,120p' docs/dependencies.md | nl -ba | sed -n '30,70p'
# Check current dependency versions
ls -la
if [ -f package.json ]; then
sed -n '1,200p' package.json | nl -ba
fi
# Also check for lockfile to infer installed versions
ls -ლა package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null || trueRepository: xDarkicex/openclaw-memory-libravdb
Length of output: 121
🌐 Web query:
Connectrpc Connect 2 removes createPromiseClient API
💡 Result:
Yes, the createPromiseClient API has been removed in ConnectRPC version 2.0.0 [1]. In Connect v2, promise-based clients are now the default [2][3]. To migrate from createPromiseClient, you should replace it with the createClient function [2][3]. Example migration: Before: import { createPromiseClient } from "@connectrpc/connect-node"; createPromiseClient(ElizaService, transport); After: import { createClient } from "@connectrpc/connect-node"; createClient(ElizaService, transport); The library provides a migration tool, @connectrpc/connect-migrate, which can automatically handle this update in your codebase [2][4]. You can run it in your project root using the command: npx @connectrpc/connect-migrate
Citations:
- 1: https://github.com/connectrpc/connect-es/releases/tag/v2.0.0
- 2: https://github.com/connectrpc/connect-es/blob/main/MIGRATING.md
- 3: connectrpc/connect-es@v2.0.0-rc.3...v2.0.0
- 4: https://www.npmjs.com/package/@connectrpc/connect-migrate
🌐 Web query:
bufbuild protobuf v2 PartialMessage export removed
💡 Result:
In version 2.0 of Protobuf-ES (@bufbuild/protobuf), the export PartialMessage was removed as part of a significant architectural shift [1][2]. In v1, PartialMessage was used to define types for constructing messages with optional fields [3][4]. With the release of v2.0, the library moved away from generating classes for Protobuf messages in favor of generating schema objects and standard TypeScript type definitions [2][5]. Because v2 no longer generates message classes that require the complex PartialMessage utility for instantiation, the type itself is no longer part of the public API [1][2]. If you are migrating to v2.0, note the following changes: - Constructors are no longer used [2][5]. Instead, you use helper functions (such as create()) that work directly with the generated schema objects and TypeScript types [5]. - The library now generates "plain" message objects, simplifying the API compared to v1 [6][2]. - Other types, such as Well-Known Types (e.g., Timestamp), have been moved to subpath exports (e.g., @bufbuild/protobuf/wkt) [1][6]. For further guidance, consult the official Protobuf-ES v2 migration guide [6].
Citations:
- 1: Missing
Timestamptyping for TS bufbuild/protobuf-es#951 - 2: https://buf.build/blog/protobuf-es-v2
- 3: Why do constructors take PartialMessage only? bufbuild/protobuf-es#561
- 4: https://github.com/timostamm/protobuf-ts/blob/main/MANUAL.md
- 5: https://github.com/bufbuild/protobuf-es/blob/main/README.md
- 6: https://protobufes.com/reference/migrating-from-v1/
🌐 Web query:
connectrpc Connect 2 transport options changed createPromiseClient replacement
💡 Result:
In Connect-ES version 2.0 and later, the createPromiseClient function has been removed [1][2]. It has been replaced by createClient, which now serves as the default method for creating clients [1][3]. Migration guidance: - You should update all call sites from createPromiseClient to createClient [1][3]. - The library provides a migration tool, npx @connectrpc/connect-migrate``, which can automatically refactor your code to use createClient [1][4]. Additionally, version 2.0 introduced changes to transport options: - The `credentials` option has been removed from transports [1][2]. - To achieve similar functionality (such as setting the `credentials` fetch option), you must now provide a `fetch` override in the transport configuration [1][3]. Example of updating the `credentials` option: // Before (v1.x) createConnectTransport({ baseUrl: "/", credentials: "include", }); // After (v2.x) createConnectTransport({ baseUrl: "/", fetch: (input, init) => fetch(input, {...init, credentials: "include" }), }); These changes are documented in the official Connect-ES migration guide [1].
Citations:
- 1: https://github.com/connectrpc/connect-es/blob/main/MIGRATING.md
- 2: https://github.com/connectrpc/connect-es/releases/tag/v2.0.0
- 3: connectrpc/connect-es@v2.0.0-rc.3...v2.0.0
- 4: v1.6.0 connectrpc/connect-es#1263
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show relevant doc context
sed -n '1,120p' docs/dependencies.md | nl -ba | sed -n '30,70p'
# Check current dependency versions
ls -la
if [ -f package.json ]; then
sed -n '1,200p' package.json | nl -ba
fi
# Also check for lockfile to infer installed versions
ls -la package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null || trueRepository: xDarkicex/openclaw-memory-libravdb
Length of output: 121
🌐 Web query:
Connectrpc Connect 2 removes createPromiseClient API
💡 Result:
Yes, ConnectRPC v2.0.0 removed the createPromiseClient API [1][2]. In ConnectRPC, promise-based clients are now the default, rendering the specific createPromiseClient function unnecessary [1][3]. As part of the transition to v2.0.0, the library was refactored to streamline client creation [2]. To migrate your codebase: 1. Replace all instances of createPromiseClient with createClient [1][4]. 2. Update your imports accordingly (e.g., from @connectrpc/connect-node or other ConnectRPC packages) [1][4]. Example migration: - import { createPromiseClient } from "@connectrpc/connect-node"; + import { createClient } from "@connectrpc/connect-node"; - createPromiseClient(ElizaService, transport); + createClient(ElizaService, transport); The ConnectRPC team provided an automated migration tool, connect-migrate, which can handle these updates for you automatically [1][5]. You can run it using: npx @connectrpc/connect-migrate [5]
Citations:
- 1: https://github.com/connectrpc/connect-es/blob/main/MIGRATING.md
- 2: https://github.com/connectrpc/connect-es/releases/tag/v2.0.0
- 3: https://context7.com/connectrpc/connect-es/llms.txt
- 4: connectrpc/connect-es@v2.0.0-rc.3...v2.0.0
- 5: v1.6.0 connectrpc/connect-es#1263
🌐 Web query:
@bufbuild/protobuf protobuf v2 PartialMessage export removed
💡 Result:
In @bufbuild/protobuf version 2.0.0 and later, the PartialMessage type export was removed from the main entry point as part of a significant architectural shift that moved away from class-based message generation [1][2][3]. In version 2, Protobuf-ES no longer generates classes for messages, instead providing schema objects and simple TypeScript types [1][3]. Because of this change, several internal types and APIs were reorganized. If you are encountering issues with missing exports like PartialMessage after upgrading to v2, note the following: 1. Relocation: While PartialMessage remains a critical type for working with generated messages, you should ensure your project structure and imports align with the v2 patterns. For some users, the transition has required adjusting how they handle message types, as the library now emphasizes generated types and schema-based functions (e.g., create(UserSchema, { ... })) [1][3]. 2. Migration Guidance: The official Protobuf-ES migration guide provides detailed steps for transitioning from v1 to v2 [4][5]. Because v2 is a major breaking change, it is recommended to review the migration documentation thoroughly, as it covers the removal of classes and the new API surface [4][1]. 3. Well-Known Types: Note that other types, such as Well-Known Types (e.g., Timestamp), have also been moved to specific subpath exports (e.g., @bufbuild/protobuf/wkt) [4][2]. If you are maintaining a project that relies on older patterns or requires interoperability with both versions during a transition, consider using package aliasing in your package.json to run v1 and v2 dependencies in parallel while migrating your codebase incrementally [5].
Citations:
- 1: https://buf.build/blog/protobuf-es-v2
- 2: Missing
Timestamptyping for TS bufbuild/protobuf-es#951 - 3: https://newreleases.io/project/github/bufbuild/protobuf-es/release/v2.0.0
- 4: https://protobufes.com/reference/migrating-from-v1/
- 5: https://github.com/timostamm/example-protobuf-es-v1-to-v2
🌐 Web query:
connectrpc Connect 2 transport options changed createPromiseClient replacement
💡 Result:
In ConnectRPC Connect-ES v2, the key changes related to transport options and client creation are: 1) createPromiseClient was removed; use createClient instead - The Connect-ES v2 migration guide states that “createPromiseClient is removed” and that call sites should be updated to use createClient (example diff provided). [1] - The v1.6.0 discussion (which introduced/managed the rename) says promises are now default and the function was renamed from createPromiseClient to the more succinct createClient. [2] 2) Transport options changed: credentials option removed; use fetch override instead - The Connect-ES v2 MIGRATING.md says the transport option credentials (and the interceptors init option) were removed because they were used to customize fetch. It provides a replacement pattern: pass a fetch override that sets credentials. [1] 3) gRPC transport HTTP/2 requirement (Connect-ES v2) - The Connect-ES compare page highlights that “gRPC transport requires HTTP/2”. [3] - The v2.0.0 release page also notes requiring HTTP/2 for the gRPC transport. [4] What this means practically (common migration pattern) - Replace: - import { createPromiseClient } … - createPromiseClient(Service, transport) with: - import { createClient } … - createClient(Service, transport) (per the v2 migration guide). [1] - Replace transport credentials usage: - Old: createConnectTransport({ credentials: "include",... }) - New: createConnectTransport({ fetch: (input, init) => fetch(input, {...init, credentials: "include" }),... }) (per MIGRATING.md). [1] If you want, tell me which packages/transport you’re using (connect-node / connect-web / grpc / connect / grpc-web) and your current code snippet, and I’ll map it line-by-line to the v2 equivalents.
Citations:
- 1: https://github.com/connectrpc/connect-es/blob/main/MIGRATING.md
- 2: v1.6.0 connectrpc/connect-es#1263
- 3: connectrpc/connect-es@v2.0.0-rc.3...v2.0.0
- 4: https://github.com/connectrpc/connect-es/releases/tag/v2.0.0
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show the exact docs section (with line numbers via awk, since nl isn't available)
awk 'NR>=30 && NR<=60 {printf "%d:%s\n", NR, $0}' docs/dependencies.md
# Inspect dependency versions
if [ -f package.json ]; then
echo "---- package.json deps ----"
cat package.json
fi
# If a lockfile exists, list it and extract likely version hints
for f in package-lock.json pnpm-lock.yaml yarn.lock; do
if [ -f "$f" ]; then
echo "---- $f (top 200 lines) ----"
sed -n '1,200p' "$f" | head -n 200
fi
doneRepository: xDarkicex/openclaw-memory-libravdb
Length of output: 13236
Add concrete upstream citations for the Connect/Protobuf v2 breaking-change rationale
docs/dependencies.md (39-44) aligns with the current codebase and upstream breaking changes: the repo imports/uses createPromiseClient and PartialMessage, and Connect-ES v2 removes createPromiseClient (use createClient) while Protobuf-ES v2 removes the PartialMessage export; Connect-ES v2 transport config also changes (e.g., credentials removed in favor of a fetch override). Add links/citations for these claims and replace the vague “transport options changed” wording with the specific breaking change(s) from the Connect-ES MIGRATING guide.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/dependencies.md` around lines 39 - 44, Update docs/dependencies.md to
cite upstream migration docs and specify exact breaking changes: mention that
Connect-ES v2 replaces createPromiseClient with createClient and that
Protobuf-ES v2 removes the PartialMessage export, and replace “transport options
changed” with the specific transport change (e.g., removal of credentials in
favor of a fetch override) with links to the Connect-ES MIGRATING guide and
Protobuf-ES v2 release/migration notes; reference the symbols
createPromiseClient, createClient, PartialMessage, and credentials/fetch in the
updated text so readers can correlate to the codebase imports and generated
contracts.
1 participant
Summary
@connectrpc/connect-node -> undici@5.29.0audit findings even though this repo has a pnpm override.overrides.undici = 6.24.0workaround for operators who need to clear the current audit path while the plugin targets Connect 1.x.Fixes #340.
Verification
@xdarkicex/openclaw-memory-libravdb@1.9.8andoverrides.undici = 6.24.0.npm ls @xdarkicex/openclaw-memory-libravdb @connectrpc/connect-node undici --all --package-lock-onlyresolves@connectrpc/connect-node@1.7.0 -> undici@6.24.0 overridden.npm audit --omit=dev --jsonreports0vulnerabilities for that throwaway install.Documentation-only PR: npm audit workaround guide
This PR adds a new section to
docs/dependencies.mdexplaining the npm audit vulnerability path caused by the plugin's dependency on@connectrpc/connect-node@1.7.0, which transitively pulls inundici@5.29.0.Key points documented:
pnpm.overridesentry for undici does not affect npm consumers, only this repository's own pnpm installoverridesentry (undici: 6.24.0) with reinstall and re-audit commandsThe documentation also preserves existing sections explaining the rationale for LibraVDB (chosen over LanceDB for its collection-level namespacing, delete operations, and local-first architecture) and Slabby (allocation-optimized slab storage for the vector-heavy workload).
Note: Complexity analysis not applicable—this is a documentation-only change with no code modifications.
Verification: Operator-performed steps confirmed the workaround effectiveness on a test project with overrides applied.
Fixes #340.