[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.

[kirin233x]

I'm not a professional front-end developer, but I think if each plugin is independent, managing all dependencies in a monorepo isn't a good approach; it's clearer and more straightforward for each sub-plugin to manage its own. The only reason I want to use a monorepo is that I plan to develop many independent plugins but don't want to create a separate Git repository for each one.

[kirin233x]

I want to try the monorepo approach again. This time, the plugin installation shows as successful, but the command line cannot find the plugin.
Here is the package.json in the root directory:
JSON{
"name": "opencli-plugins-app-team",
"private": true,
"version": "1.0.1",
"type": "module",
"workspaces": [
"packages/*"
],
"devDependencies": {
"@types/node": "^25.5.0",
"typescript": "^6.0.2"
}
}
opencli plugin list shows that the plugin is installed successfully, but the command line reports that it cannot be found.
I had GLM analyze the source code, and it believes the following code has a bug:
Bug in the already installed opencli (in plugin.js:1107):
JavaScript// thisFile = .../opencli/dist/src/plugin.js
// dirname = .../opencli/dist/src/
// ".." = .../opencli/dist/ ← This is wrong! It should be the package root directory.
const hostRoot = path.resolve(path.dirname(thisFile), '..');
Result: The symlink points to dist/ instead of the package root directory. There is no package.json in the dist/ folder, so Node.js cannot resolve the exports mapping, and @jackwener/opencli/registry fails to resolve.
Symlink:
textpackages/huawei-dts/node_modules/@jackwener/opencli → .../opencli/dist
↑ No package.json here, exports mapping is broken
It should correctly point to:
text.../opencli/
↑ Has package.json, ./registry → dist/src/registry-api.js ✓

[KehaoC]

I opened a narrower fix for the host-root part discussed in the latest comment: #852

This does not try to resolve the broader monorepo dependency-install policy for sub-plugin runtime dependencies. It specifically fixes the case where the installed plugin symlink points node_modules/@jackwener/opencli at dist/ instead of the package root, which would make exports like @jackwener/opencli/registry fail to resolve.