Repository navigation
fix(plugin): report configured plugin directories without an entrypoint - #58767
Irish-Joseph wants to merge 1 commit into
Conversation
A directory listed under plugins that contains no entrypoint was filtered out during the source scan, so it never loaded and never reported. Keep such directories in the operation list so the loader surfaces them as failed plugins with a clear error. Closes anomalyco#58574
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
Requesting changes. I ran the new test on the base branch, where it fails because the empty directory is never reported, and with this PR, where it passes. The packages/core plugin tests pass (432) and tsc is clean.
The new behaviour also catches valid directories, though. In a temporary probe test (removed afterwards), a configured directory with only tui.ts and a helper folder found by auto-discovery (.opencode/plugins/helpers/util.ts) were both listed as failed with Plugin entrypoint not found. On the base branch neither shows up. Users would see false failures in GET /api/plugin and the TUI for TUI-only plugins and for any helper subfolder under .opencode/plugins/. Details are in the inline comment.
Public API: unchanged. The only difference is which local plugins show up as failed in the plugin list.
| : { server: pathToFileURL(operation.target).href } | ||
| if (!entrypoints.server) return [] | ||
| if (directory) { | ||
| if (directory && entrypoints.server) { |
There was a problem hiding this comment.
This loop also runs for the auto-discovered entries (discovered from PluginSourceDirectory.discover). discover returns every subdirectory of .opencode/plugin(s)/, so a helper folder like .opencode/plugins/helpers/ is now reported as a failed plugin. The check also only looks at server, so a directory with only a tui (or rpc) entrypoint is reported as failed too, even though it's a valid TUI-only plugin that the TUI loads itself. I reproduced both: neither appears on the base branch, and with this PR both are listed as failed with Plugin entrypoint not found.
Suggested fix: keep the early return [] for discovered entries and for directories that have a tui or rpc entrypoint. Only keep directories that were explicitly configured and have no entrypoint at all, for example by marking the configured operations before they're merged with the discovered ones.
|
The check, test and nix-eval suites are stuck at "action required" for this fork, so they haven't run. I ran the same steps locally and everything is green: bun run lint (0 problems), typecheck:tsc (all packages), and the core plugin suite (404 tests, 0 failures). Would a maintainer be able to approve and run the workflows? Thanks. |
Issue for this PR
Closes #58574
Type of change
What does this PR do?
A directory listed under
pluginsthat contains no entrypoint was dropped during the source scan:scanreturned[]whenresolvefound no server entrypoint, so the directory never reached the loader. It silently never loaded and was never reported as failed, even though a misconfigured path is worth surfacing.The scan now keeps directories without an entrypoint in the operation list (the
resolvecontainment check still applies when an entrypoint exists). The loader then loads the directory, finds no entrypoint, and reports the plugin asfailedwithPlugin entrypoint not found: <path>.How did you verify your code works?
supervisor-reload.test.ts: a configured directory containing only a text file surfaces as a failed local plugin with the "entrypoint not found" error. Without the fix the test fails — activation never reports the plugin at all, which is the silent-drop the issue reports.bun run typecheckclean,bun run lintclean.pluginsinopencode.json, start opencode, and the plugin now shows as failed with the entrypoint error instead of disappearing.Screenshots / recordings
Not a UI change.
Checklist