You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Plugins that depend on npm packages using the bindings module to locate native .node addons fail because jiti sets module.filename to its own path rather than the plugin's source path. The bindings package walks up from module.filename looking for build/Release/*.node, but since the filename points to jiti internals, it never finds the binary.
This is distinct from the two issues already fixed:
This third issue affects any plugin dependency that uses the bindings package to resolve native addons, including sqlite3, better-sqlite3, and others.
Steps to Reproduce
Install a plugin that depends on sqlite3 (e.g., @mem0/openclaw-mem0 with mode: "open-source")
npm rebuild sqlite3 in the plugin directory — binary builds successfully
Start the gateway — plugin fails with Could not locate the bindings file
Verification that the binary works outside jiti:
node -e "require('./node_modules/sqlite3')"# Works perfectly
Inside jiti (via gateway plugin load):
Error: Could not locate the bindings file. Tried:
→ /path/to/jiti/internals/build/Release/node_sqlite3.node
→ ... (13 search paths, all rooted at jiti's location)
Expected Behavior
module.filename should be set to the plugin's entry point path before jiti evaluates the plugin, so that bindings (and any other package using module.filename for path resolution) resolves native addons relative to the plugin directory.
Suggested Fix
The plugin loader should set module.filename (and potentially module.paths) to the plugin's source path before jiti evaluation, similar to how #13109 re-anchors globalThis.require.
Environment
OpenClaw: 2026.2.19
macOS 15.3 arm64 (Apple M4)
Node: 22.22.0
Affected packages: sqlite3 (via bindings), potentially better-sqlite3 and any native addon using bindings
Description
Plugins that depend on npm packages using the
bindingsmodule to locate native.nodeaddons fail because jiti setsmodule.filenameto its own path rather than the plugin's source path. Thebindingspackage walks up frommodule.filenamelooking forbuild/Release/*.node, but since the filename points to jiti internals, it never finds the binary.This is distinct from the two issues already fixed:
requireunavailable — fixed by fix(plugins): inject globalThis.require for CJS interop in jiti-loaded extensions #13109 (globalThis.requireshim)This third issue affects any plugin dependency that uses the
bindingspackage to resolve native addons, includingsqlite3,better-sqlite3, and others.Steps to Reproduce
sqlite3(e.g.,@mem0/openclaw-mem0withmode: "open-source")npm rebuild sqlite3in the plugin directory — binary builds successfullyCould not locate the bindings fileVerification that the binary works outside jiti:
Inside jiti (via gateway plugin load):
Expected Behavior
module.filenameshould be set to the plugin's entry point path before jiti evaluates the plugin, so thatbindings(and any other package usingmodule.filenamefor path resolution) resolves native addons relative to the plugin directory.Suggested Fix
The plugin loader should set
module.filename(and potentiallymodule.paths) to the plugin's source path before jiti evaluation, similar to how #13109 re-anchorsglobalThis.require.Environment
bindingsRelated
requireshim — does not address this)cc @mcaxtr @lukeboyett
This issue was filed by an AI agent (Nix) on behalf of @RedactedFoundry, following up on the discussion in #12854.