bug: `opencli --version` reports `0.0.0` when installed from source + `Failed to load module` for user clis

[AhogeK]

Description

When installing from source (as documented in the README under For Developers), two issues occur simultaneously:

1. opencli --version always reports 0.0.0 instead of the actual version.
2. Every command in ~/.opencli/clis/ fails with Failed to load module ... Cannot find module '/Users/<user>/.opencli/src/registry.js'.

---

Environment

• Install method: from source (git clone → npm install → npm run build → npm link / pnpm link --global)
• Node: v24.14.1 (via nvm)
• npm: latest
• OS: macOS
• opencli version (package.json): 1.6.3

---

Steps to Reproduce

git clone git@github.com:jackwener/opencli.git && cd opencli
npm install
npm run build
npm link   # or: pnpm link --global
opencli --version
opencli doctor

---

Root Cause Analysis

Bug 1 — version reports 0.0.0

src/version.ts resolves package.json with one level up from __dirname:

// src/version.ts
const pkgJsonPath = path.resolve(__dirname, '..', 'package.json');

At runtime after npm run build, __dirname is dist/src/. One level up is dist/, where no package.json exists. The try/catch silently falls back to '0.0.0'.

This works fine for npm install -g users because npm automatically includes the root package.json in the published package, placing it at <package-root>/package.json — exactly one level above dist/src/. But when running from a cloned repo, the root package.json is two levels above dist/src/.

Fix:

- const pkgJsonPath = path.resolve(__dirname, '..', 'package.json');
+ const pkgJsonPath = path.resolve(__dirname, '..', '..', 'package.json');

Bug 2 — Failed to load module ~/.opencli/clis/*.js

The postinstall / fetch-adapters.js script downloads pre-compiled .js adapter files into ~/.opencli/clis/. These files contain hardcoded absolute-style imports:

Cannot find module '/Users/<user>/.opencli/src/registry.js'
Cannot find module '/Users/<user>/.opencli/src/errors.js'

However, ~/.opencli/src/ is never created — the core runtime lives inside the npm package's dist/src/, not under ~/.opencli/. These pre-compiled clis appear to have been built against an older layout where the source was symlinked or copied into ~/.opencli/src/.

Workaround (user-side): rm -rf ~/.opencli/clis/ causes opencli to fall back to the built-in YAML-driven commands in dist/clis/, avoiding the broken imports entirely.

---

Expected Behavior

• opencli --version → 1.6.3
• opencli doctor → no Failed to load module warnings

Actual Behavior

• opencli --version → 0.0.0
• Hundreds of ⚠ Failed to load module warnings for every adapter in ~/.opencli/clis/

---

Suggested Fix

For Bug 1, the one-line change above in src/version.ts is sufficient. It is backward-compatible: when installed via npm install -g, the root package.json is still two levels above dist/src/ inside the installed package directory.

For Bug 2, the pre-compiled .js files distributed by fetch-adapters.js may need to be rebuilt with correct import paths that resolve against the npm package's installed location rather than ~/.opencli/src/.

[jerry0804]

The same problem occurs with npm install -g.

[Astro-Han]

I checked the published @jackwener/opencli@1.6.3 package, and both reported symptoms do look real.

One small refinement on the root cause analysis:

• The version issue seems correct: in the published package, version.js runs from dist/src/, but it resolves ../package.json, which points to dist/package.json instead of the package root, so it falls back to 0.0.0.
• The adapter load failure also seems correct, but it looks more like a shim layout mismatch than hardcoded absolute imports. The published adapter files import ../../src/registry.js and ../../src/errors.js, which resolve to ~/.opencli/src/... after being copied into ~/.opencli/clis/.... The current compat shims appear to be created under ~/.opencli/*.js, not ~/.opencli/src/*.

So the two issues seem to be:

• wrong package.json lookup for version
• mismatch between published adapter import paths and generated compat shim paths

[jeshy]

OMG！ The same problem occurs

[Astro-Han]

Opened #789 with a minimal fix (2 files, ~13 lines):

1. version.ts: walk up one more level when package.json isn't at the first parent — covers both dev (src/) and prod (dist/src/) layouts.
2. discovery.ts: derive src/ compat shims from the existing rootShims list, so ~/.opencli/src/{registry,errors,...}.js are created alongside the root-level shims.

Both issues trace back to #784 changing rootDir from "src" to ".".

[Astro-Han]

Temporary workaround before the fix is merged and released:

Please downgrade to @jackwener/opencli@1.6.2 for now. Based on the published packages, 1.6.2 still uses the previous layout and does not appear to have this regression.

Global install:

npm uninstall -g @jackwener/opencli
npm install -g @jackwener/opencli@1.6.2

This should avoid both the adapter/shim path issue from 1.6.3 and, in the related reports, the incorrect 0.0.0 version output.

Once the fix is released, users can upgrade again.