Repository navigation
[Bug]: Plugins with native NAPI dependencies return empty module ({}) since v1.3.8 plugin loader refactor #20623
Description
Description
Since v1.3.8, npm plugins that depend on native Node.js NAPI addons (.node binaries) receive an empty module object when importing the native dependency. The external dependency resolves to {} with zero keys inside the plugin runtime, despite the package existing correctly in ~/.cache/opencode/node_modules/.
This was introduced by the plugin loader refactor in PR #20112. The fix in #20140 (v1.3.9) resolved a separate entrypoint path issue but did not fix native module resolution.
Affected plugin
- codexfi (
@lancedb/lancedb— native NAPI addon with.nodebinary) - Likely affects any plugin using native deps:
sharp,better-sqlite3,@libsql/client, etc.
Steps to Reproduce
- Install OpenCode Desktop v1.3.8 or later (tested on v1.3.13)
- Add a plugin that depends on a native NAPI module:
{ "plugin": ["codexfi"] } - The plugin's
import * as lancedb from "@lancedb/lancedb"resolves to an empty object - Plugin logs:
TypeError: lancedb.connect is not a function. (In 'lancedb.connect(dbPath)', 'lancedb.connect' is undefined) - Diagnostic logging shows:
Keys: []— the import is completely empty
Expected Behavior
import * as lancedb from "@lancedb/lancedb" should resolve to the actual module with all exports (connect, Connection, Table, etc.), as it does in v1.3.7.
Actual Behavior
The import resolves to {} (empty object, zero keys). The native .node binary in ~/.cache/opencode/node_modules/@lancedb/lancedb-darwin-arm64/ is never loaded.
Verification
| Test | Result |
|---|---|
| OpenCode Desktop v1.3.7 | Plugin works — [MEMORY] injected in logs |
| OpenCode Desktop v1.3.13 | Plugin broken — Keys: [], empty import |
Standalone bun -e "import * as l from '@lancedb/lancedb'..." from cache dir |
Works — connect: function |
Standalone node -e "require('@lancedb/lancedb')" from cache dir |
Works — connect: function |
Both bare path and file:// URL imports from standalone Bun |
Work correctly |
The native module resolves correctly in every context except inside OpenCode's embedded plugin runtime on v1.3.8+.
Root Cause Analysis
PR #20112 refactored plugin loading into PluginLoader.resolve() → PluginLoader.load(). The key change is how plugin entrypoints are resolved via resolvePackagePath() which uses pathToFileURL(). While the entrypoint itself resolves, the external dependencies of the loaded module (those marked --external in the plugin's build) fail to resolve inside OpenCode's embedded Bun runtime.
The plugin bundle uses import * as lancedb from "@lancedb/lancedb" (kept as external by bun build --external @lancedb/lancedb). In v1.3.7, the runtime resolved this from ~/.cache/opencode/node_modules/. In v1.3.8+, the resolution returns an empty module.
Note: OpenCode v1.3.7 embeds Bun 1.2.8, while v1.3.13 embeds Bun 1.3.11 — the embedded Bun version change may also contribute.
Workaround
Downgrade OpenCode Desktop to v1.3.7.
Environment
- macOS 26.3 (Apple Silicon)
- OpenCode Desktop v1.3.13 (broken), v1.3.7 (working)
- Plugin: codexfi 0.5.1
- Native dep: @lancedb/lancedb 0.15.0 (@lancedb/lancedb-darwin-arm64)
Activity
clarkbalan commentedon Apr 2, 2026
Update: Issue resolved after clean upgrade path
After further testing, the issue does not reproduce when upgrading through each version sequentially (1.3.7 → 1.3.8 → 1.3.9 → ... → 1.3.13). Every version works correctly when upgraded this way.
The issue only occurred after the desktop app auto-updated directly from an older version to 1.3.13. The plugin cache (
~/.cache/opencode/node_modules/) was stale or corrupted from the jump —@lancedb/lancedbresolved to an empty object ({}, zero keys) inside the plugin runtime, despite the files existing correctly on disk.What fixed it
bun installof all plugin deps)Root cause hypothesis
When the desktop app auto-updates (e.g. skipping from 1.2.x or 1.3.7 directly to 1.3.13), the plugin cache from the old plugin loader format isn't properly invalidated or rebuilt for the new loader introduced in PR #20112. The cached native module artifacts (
.nodeNAPI binaries) exist on disk but the new loader can't resolve them from the stale cache state.A sequential upgrade works because each version's startup runs
bun installwhich incrementally rebuilds the cache correctly.Suggested fix
When the plugin loader detects a version change (or on any major plugin loader refactor), the plugin cache should be fully invalidated and rebuilt. The
CACHE_VERSIONconstant exists but may not have been bumped for the 1.3.8 loader refactor.Environment
fix: revert db.ts to simple createRequire — 0.5.3 broke lancedb loadi…
github-actions commentedon Jul 3, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.