TUI plugin fails to load on registry installs: dist/tui.js statically imports @opentui/solid, which is only in devDependencies #35

Activity

1. MrDoe

   added a commit that references this issue on Oct 19, 2026

   fix(plugin): restore TUI integration on OpenCode 2 (see #35)

   ...

   41c5962
2. MrDoe commented on Oct 19, 2026

   

   MrDoe

   on Oct 19, 2026

   Owner

   More actions

   Fixed in v2.4.5 — thank you for the pinpoint report, @rodrigocora. The devDependencies analysis and the ResolveMessage trace made this a five-minute diagnosis.

   Your root cause is exactly right, and while reproducing it with a clean registry install we found a second, independent breakage on OpenCode 2. Both are fixed:

   1. @opentui/solid is now imported lazily

   dist/tui.js no longer touches @opentui/solid at module scope. The import moved inside loadOpenTui(), which is only reached from the TUI branch of setup() (which returns early for server-role loads). Verified by copying dist/ into a tree with no node_modules at all: the module imports cleanly, server-role setup({}) is a no-op, and only the TUI path attempts the import — where OpenCode's runtime provides it.

   @opentui/core, @opentui/solid and solid-js are now declared as optional peerDependencies (>=0.5.10, matching what @opencode/plugin itself requires):

   "peerDependenciesMeta": {
     "@opentui/core": { "optional": true },
     "@opentui/solid": { "optional": true },
     "solid-js": { "optional": true }
   }

   The OpenCode TUI runtime rewrites these specifiers from its own bundle (@opentui/core/runtime-plugin.js handles them, dynamic imports included), so plain registry installs never need to resolve them locally — which is also why the bug only ever surfaced outside --include=dev / symlinked trees, exactly as you observed.

   2. OpenCode 2 loads TUI plugins only from directories (found while testing your shim layout)

   OpenCode 2's TUI discovery (packages/tui/src/plugin/discovery.ts) keeps only directories/symlinks under .opencode/plugins/ — a flat *.js file registers in the server role only, silently. Workspaces initialized by older versions had exactly that flat layout, so even with the import fixed the sidebar would never appear. init / setup now write:

   .opencode/plugins/opencode-rag/
   ├── index.js   ← server role
   └── tui.js     ← terminal UI
   

   and migrate the V1 flat entries + .opencode/tui.json away — but only when a file's content exactly matches what the old init generated, so anything hand-written is kept and reported.

   While in there

   • providers/models are read from data.location.provider/model.list(location) (legacy shape kept as fallback)
   • the sidebar now reports the plugin's own version instead of context.app.version (which is OpenCode's own)

   Updating

   npm update -g opencode-rag-plugin    # or: npm install opencode-rag-plugin@latest in ~/.opencode
   opencode-rag setup                   # re-sync the runtime symlink
   opencode-rag init                    # rewrite the workspace plugin files in the new directory layout

   For your ~/.opencode dependency install, updating the package there is enough — your shim keeps working, since the @opentui/solid import is now deferred to the TUI setup path, where OpenCode's runtime resolves it.

   Restart OpenCode afterwards and you should get the sidebar back, plus the settings dialog (ctrl+shift+r), the file-list injector (ctrl+enter) and the RAG-chunks injector (ctrl+alt+enter). Plugin load failures still land in ~/.local/share/opencode/log/opencode.log, and doc/troubleshooting.md now documents the expected layout if anything looks off.

   Thanks again — reports like this are why the fix ended up covering both failure modes. 🙏
3. MrDoe

   closed this as completedon Oct 19, 2026
4. MrDoe

   self-assigned this

   on Oct 20, 2026
5. MrDoe

   added

   bugSomething isn't workingSomething isn't working

   on Oct 20, 2026