[Bug]: cannot find undici when install plugin.

[kirin233x]

Description

here is my package.json of my plugin.
{
"name": "opencli-plugin-codehub",
"version": "1.0.1",
"type": "module",
"peerDependencies": {
"@jackwener/opencli": ">=1.0.0"
},
"dependencies": {
"undici": "^7.0.0"
},
"devDependencies": {
"@types/node": "^25.5.0",
"typescript": "^6.0.2"
}
}

when I install plugin
Plugin codehub/commands.js: Cannot find package 'undici' imported from /Users/xxxxxx/.opencli/monorepos/opencli-plugins-app-team/packages/codehub/codehub.js

Steps to Reproduce

1. Run opencli ...
2. ...
3. See error

Expected Behavior

install success.

OpenCLI Version

1.6.1

Node.js Version

22.x

Operating System

macOS

Logs / Screenshots

[Astro-Han]

Thanks for the report. I looked through the current plugin install flow, and this seems to be a real gap in OpenCLI's monorepo plugin handling, not just a one-off undici problem.

From the current implementation, monorepo sub-plugins are installed with this assumption:

1. OpenCLI clones the monorepo once
2. It runs npm install --omit=dev only at the monorepo root
3. It then symlinks each sub-plugin into ~/.opencli/plugins/...
4. For TS plugins, it links the host @jackwener/opencli package and transpiles .ts to .js

The important part is step 2: OpenCLI does not install dependencies inside each sub-plugin directory. It assumes the monorepo root is already set up to provide those dependencies, typically via npm workspaces.

That assumption is currently not validated.

So if a sub-plugin has its own runtime dependencies, for example undici in its package.json, but the monorepo root is not correctly configured to install and expose that package for the sub-plugin, the install step can appear to succeed, while the plugin later fails at runtime with:

Cannot find package 'undici'

That matches the behavior in this issue.

Concretely, the code today does the following:

• installDependencies(dir) runs npm install --omit=dev for the given directory if it has a package.json
• standalone plugins call that on the plugin directory
• monorepo plugins call that only once on the repo root, not on each sub-plugin
• monorepo sub-plugin validation checks plugin structure, but does not check whether the root workspace setup will actually install the sub-plugin's dependencies

Because of that, the current behavior can become:

• install succeeds
• plugin is linked successfully
• first command execution fails due to missing runtime dependency

So I think the issue should be framed as:

OpenCLI currently assumes monorepo root dependency installation is sufficient for all sub-plugins, but it does not verify that assumption or fail early when it is false.

This likely affects more than undici. Any monorepo sub-plugin with runtime dependencies can hit the same problem if the repo root does not properly manage those dependencies.

I do not want to jump straight to a fix yet, because this touches the core plugin install model and there is a design choice to make:

• strict validation:
  fail during install unless the monorepo root is clearly configured to manage sub-plugin dependencies
• fallback installation:
  if root install is not enough, also install dependencies in the sub-plugin directory
• documentation-only:
  probably not sufficient, because the current behavior fails late at runtime instead of clearly during install

If someone wants to pick this up, the main areas to inspect are the monorepo install lifecycle and validation logic in src/plugin.ts, especially the monorepo path that installs dependencies only at the repo root.

As a temporary workaround for plugin authors, the safest approach is:

• make sure the monorepo root is configured as a proper npm workspace root
• make sure the sub-plugin package is included in that workspace
• make sure runtime dependencies like undici are actually installed from the root in a way Node can resolve from the sub-plugin path

I think this issue is valid and worth keeping open for discussion before deciding the exact fix.