v1.4.2: onnxruntime-common not hoisted on Linux/WSL2 — clean-install repro of #95 Bug 2 (conflicting versions confirmed)

[jtarmstrong]

Summary

On a clean Linux (WSL2) install of episodic-memory@1.4.2, onnxruntime-common is not hoisted to top-level node_modules/. It is physically nested under both onnxruntime-node and onnxruntime-web, each carrying a different version, so npm cannot hoist either. @huggingface/transformers's bare import { Tensor } from "onnxruntime-common" then fails with ERR_MODULE_NOT_FOUND.

This is a clean-install reproduction of Bug 2 from #95, which was closed as "does NOT reproduce — onnxruntime-common IS hoisted on clean installs (macOS + Windows 11)." It reproduces deterministically here on Linux, so it is not the Windows-postinstall red herring suspected in that thread — it's a genuine cross-platform npm hoisting failure driven by conflicting onnxruntime-common versions.

Environment

• Plugin: episodic-memory@1.4.2 (via superpowers-marketplace)
• OS: Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 (WSL2)
• Node: v22.22.1
• npm: 10.9.4

Evidence

1. onnxruntime-common is not at top-level — it's nested under both parents:

$ ls node_modules/onnxruntime-common
ls: cannot access 'node_modules/onnxruntime-common': No such file or directory

$ find node_modules -name onnxruntime-common -type d
node_modules/onnxruntime-web/node_modules/onnxruntime-common
node_modules/onnxruntime-node/node_modules/onnxruntime-common

2. The two parents pull conflicting versions — this is why npm won't hoist either:

node_modules/onnxruntime-web/node_modules/onnxruntime-common   -> 1.24.0-dev.20251116-b39e144322
node_modules/onnxruntime-node/node_modules/onnxruntime-common  -> 1.24.3

@huggingface/transformers declares only the two parents, not onnxruntime-common itself:

"onnxruntime-node": "1.24.3",
"onnxruntime-web": "1.26.0-dev.20260416-b7804b056c"

3. The bare import fails (both CJS resolve and the real ESM entry point):

$ node -e "require.resolve('onnxruntime-common')"
Error: Cannot find module 'onnxruntime-common'

$ node --input-type=module -e "import('@huggingface/transformers')"
Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'onnxruntime-common'
  imported from .../episodic-memory/1.4.2/node_modules/@huggingface/transformers/dist/transformers.node.mjs
  code: 'ERR_MODULE_NOT_FOUND'

Re: the npm ls clarification in #95 — agreed that npm ls shows the logical tree. The evidence above is the physical layout (find ... -type d + a top-level ls that 404s + require.resolve failing), which is what was requested. onnxruntime-common genuinely is not hoisted here.

Impact

• The SessionStart hook (episodic-memory.js sync --background) fails silently (it's --background), so background conversation indexing never runs.
• search-conversations / remembering-conversations hit the same ERR_MODULE_NOT_FOUND when invoked.
• A cosmetic startup warning surfaces, but the session is otherwise unaffected (non-blocking).

Why this differs from the #95 close

The #95 close reasoned that onnxruntime-common is always hoisted on a clean install and that the reporter's real problem was the Windows-only postinstall redirection (2>/dev/null || true, fixed in a3438a6). On Linux that postinstall path is fine, yet the non-hoist still happens — because onnxruntime-node@1.24.3 and onnxruntime-web@1.26.0-dev… depend on incompatible onnxruntime-common versions (1.24.3 vs 1.24.0-dev…). With two conflicting versions, npm must nest at least one, and here it nests both, leaving top-level empty. Whether it hoists is install-order / npm-version sensitive, which likely explains why it didn't reproduce in the earlier macOS/Windows tests.

Suggested fixes (any one resolves it)

1. Declare onnxruntime-common as a direct dependency of the plugin, pinned to a single version, so it hoists to top-level deterministically.
2. Add an overrides entry forcing a single onnxruntime-common across onnxruntime-node/onnxruntime-web, so only one version exists and it hoists.
3. As a defensive fallback, have the wrapper require.resolve('onnxruntime-common') as a sentinel (like the post-Plugin fails to load on Windows: two upstream dep-resolution bugs slip past mcp-server-wrapper.js #95 manifest probe) and re-install / symlink if missing — though (1) or (2) is the real fix and belongs upstream.

---

Filed via Claude Code after reproducing locally. Happy to run any additional find / npm diagnostics on this WSL2 install.