[Windows] Adapter modules fail to load - incorrect import paths (src/ instead of dist/src/)

[ufomaker]

Bug Description

On Windows, after installing @jackwener/opencli@latest via npm, all adapter modules fail to load with "Cannot find module" errors. The adapters are importing from src/registry.js and src/errors.js, but these files should be in dist/src/ after compilation.

Environment

• OS: Windows 10/11
• Node.js: v22.16.0
• npm: latest
• opencli: v1.6.3 (installed via npm install -g @jackwener/opencli@latest)

Installation Steps

powershell
Clean install
npm uninstall -g @jackwener/opencli
npm cache clean --force
npm install -g @jackwener/opencli@latest

Error Output

When running any opencli command (e.g., opencli --version or opencli list):

⚠ Failed to load module C:\Users\Administrator.opencli\clis\1688\item.js: Cannot find module 'C:\Users\Administrator.opencli\src\errors.js' imported from C:\Users\Administrator.opencli\clis\1688\item.js
⚠ Failed to load module C:\Users\Administrator.opencli\clis\amazon\bestsellers.js: Cannot find module 'C:\Users\Administrator.opencli\src\registry.js' imported from C:\Users\Administrator.opencli\clis\amazon\bestsellers.js
... (hundreds of similar errors for all adapters)

Expected Behavior

The adapters should import from the compiled dist/src/ directory, not the source src/ directory.

Root Cause Analysis

The adapter files in clis/ directory have import statements like:

javascript
import { cli } from 'src/registry.js';

But after npm install, the compiled files should be in:

C:\Users\Administrator\AppData\Roaming\npm\node_modules@jackwener\opencli\dist\src\registry.js

Possible Solutions

1. Fix import paths in adapters - Change imports from src/ to dist/src/ for published packages
2. Use package.json exports - Define proper exports in package.json to resolve imports correctly
3. Postinstall script - Fix import paths during postinstall on Windows

Additional Context

• The issue appears on Windows only (Unix-like systems may handle relative paths differently)
• The opencli --version command does return 0.0.0, indicating the core CLI works
• Only adapter loading fails

Workaround

Currently, only core commands work (e.g., opencli --help, `open

[Astro-Han]

Thanks for reporting this. This looks closely related to #788, specifically the adapter/shim path mismatch in 1.6.3.

The failure mode appears to be the same: adapters copied into ~/.opencli/clis/ or %USERPROFILE%\\.opencli\\clis\\ import paths like ../../src/registry.js and ../../src/errors.js, which then resolve to ~/.opencli/src/* or the Windows equivalent. The generated compatibility shims do not currently match that src/ layout, so the modules fail to load.

So this looks like the same underlying issue as the second half of #788. The extra --version => 0.0.0 regression tracked in #788 is a separate problem.

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