Support monorepo-friendly plugin installation and discovery

[Amorites]

Support monorepo-friendly plugin installation and discovery

Summary

OpenCLI plugin installation and discovery currently work best when each plugin lives in its own standalone repository and is installed into a flat directory under ~/.opencli/plugins/<name>/.

This works well for simple community plugins, but it becomes limiting for teams that want to maintain multiple related plugins in a single monorepo.

Current behavior

From the current implementation and docs:

• opencli plugin install only supports:
  • github:user/repo
  • https://github.com/user/repo
• Installed plugins are expected to live in:
  • ~/.opencli/plugins/<name>/
• Plugin discovery treats each subdirectory under ~/.opencli/plugins/ as one plugin
• Files are scanned flat inside that plugin directory
• Nested plugin directories are not discovered

This means a monorepo like:

automation-plugins/
  packages/
    opencli-plugin-team/
    opencli-plugin-kim/

cannot be used directly with the current install/discovery model.

Why this matters

For internal automation teams, monorepos are often the most practical way to manage multiple OpenCLI plugins because they allow:

• shared helpers and runtime utilities
• shared docs and setup scripts
• consistent linting / testing / release flow
• cross-plugin workflows, for example one plugin reading data from one system and another plugin writing to another system

Without monorepo support, users need to:

• keep one repo per plugin, or
• write custom sync scripts that copy subdirectories into ~/.opencli/plugins/<name>/

Both workarounds are manageable, but they make plugin maintenance harder than it needs to be.

Requested improvements

Any of the following would help a lot:

Option 1: support local path install

Allow installing from a local plugin directory:

opencli plugin install /path/to/plugin
opencli plugin install /path/to/repo/packages/team

This would already make monorepo workflows much easier.

Option 2: support repository subdirectory install

Allow installing a plugin from a repo subdirectory, for example:

opencli plugin install github:user/repo//packages/team
opencli plugin install https://github.com/user/repo//packages/team

This would preserve the current mental model while enabling monorepos.

Option 3: support workspace-style plugin manifests

Allow a top-level repo to declare plugin package locations, something like:

{
  "plugins": [
    "packages/team",
    "packages/kim"
  ]
}

Then OpenCLI could discover and install each package as a plugin.

Additional note

It would also be useful if plugin install supported more git hosts beyond GitHub, or at least generic git URLs / local paths, since many teams use GitLab or self-hosted git.

Relevant implementation details

The current behavior appears to come from:

• plugin install source parsing only handling GitHub sources
• discoverPlugins() scanning only immediate subdirectories under ~/.opencli/plugins/
• discoverPluginDir() doing flat file scans instead of recursive package discovery

Expected outcome

The smallest improvement that would unlock most monorepo workflows is probably:

1. support installing from a local path
2. support installing from a repository subdirectory

That would let teams manage plugins in monorepos without changing the current plugin runtime model too much.

Thanks for building OpenCLI. The current plugin model is already very approachable, and monorepo-friendly installation would make it much easier to scale to multi-plugin internal automation setups.

[ByteYue]

Thanks for your advice. Actually plugin manifests is what we're currently designing, coming soon~.

[ByteYue]

Option 1 could currently be addressed by just using symlink your plugin code into ~/.opencli/plugins/.

[ByteYue]

Try #475 .