[Bug]: pi-fff cannot load under omp (Oh My Pi) — Bun-compiled pi runtime misdetected as 'bun'

[manooog]

Bug: pi-fff fails to load in omp (Oh My Pi) — Bun-compiled pi runtime misdetected as "bun"

Summary

@ff-labs/pi-fff (the pi extension behind fffind/ffgrep) fails to load inside omp (Oh My Pi), a coding harness that embeds @earendil-works/pi-coding-agent compiled into a single Bun binary. Every fffind/ffgrep call errors with:

ResolveMessage: Cannot find module '@ff-labs/fff-bun' from '~/.omp/plugins/node_modules/@ff-labs/pi-fff/src/sdk.ts?mtime=...'

The module is installed and complete — it just cannot be resolved at runtime.

Environment

• omp (Oh My Pi), plugin installed via its ~/.omp/plugins mechanism (bun.lock, @ff-labs/pi-fff@0.10.3)
• Linux x64, glibc
• Plugin dir: ~/.omp/plugins/node_modules/@ff-labs/{pi-fff,fff-bun,fff-node,fff-bin-linux-x64-gnu} — all present, freshly installed

Root cause analysis

pi-fff/src/sdk.ts chooses the SDK at runtime:

function detectRuntime(): "bun" | "node" {
  if (typeof (globalThis as { Bun?: unknown }).Bun !== "undefined") return "bun";
  if (typeof process !== "undefined" && (process as { versions?: { bun?: string } }).versions?.bun) return "bun";
  return "node";
}
// const pkg = detectRuntime() === "bun" ? "@ff-labs/fff-bun" : "@ff-labs/fff-node";

omp is a Bun-compiled standalone binary (its logs show the embedded fs: /$bunfs/root/packages/coding-agent/src/cli.js), so globalThis.Bun exists. detectRuntime() therefore returns "bun" and the extension dynamically imports @ff-labs/fff-bun, whose entry is TypeScript source:

// @ff-labs/fff-bun/package.json
"main": "src/index.ts",
"exports": { ".": { "import": "./src/index.ts", "types": "./src/index.ts" } }

omp's module resolver (Node semantics, error type ResolveMessage) cannot load .ts files under node_modules — the same failure Node 24 reports as Stripping types is currently unsupported for files under node_modules. The import fails, reported as Cannot find module.

The JS-compiled sibling @ff-labs/fff-node (main: dist/src/index.js) would work fine, but it is never selected because the runtime is misdetected as bun.

Evidence

• bun -e "import('@ff-labs/fff-bun')" from the plugins dir: succeeds (plain Bun handles TS fine)
• node -e "import('@ff-labs/fff-bun')": fails with Stripping types is currently unsupported for files under node_modules — the package is found, the entry type is the problem
• Restarting omp does not help (structural, not a stale-cache issue)
• omp's own log shows the same resolver limitation for another external package: ResolveMessage: Cannot find module 'fastembed/package.json' from '/$bunfs/root/packages/coding-agent/src/cli.js'
• Native pi (@earendil-works/pi-coding-agent, engines node >= 22.19.0) has no globalThis.Bun, detects "node", uses fff-node — works fine. This is specific to Bun-compiled hosts of pi.

Suggested fixes (any would unblock)

1. Publish a compiled-JS entry for @ff-labs/fff-bun (or point main at a dist/ build) — most robust, mirrors fff-node.
2. Make detectRuntime() probe actual loading capability instead of globalThis.Bun (e.g. try importing the JS build first, or check process.versions.bun only — note a Bun-compiled binary does set process.versions.bun too, so neither global probe is reliable here; an env-var override or capability probe is needed).
3. Expose an override (env var like FFF_SDK=node) so Bun-compiled hosts can force the Node SDK.

Happy to provide more logs or test a fix if useful.

[dmtrKovalenko]

Wait isn’t oh my pi uses bun. I think I fixed it to work correctly why do you think it should use node

[gustav-fff]

[triage-bot] LINKED PR: #779 — #779 (state: OPEN)

PR #779 fixes this by making loadSdk() in src/sdk.ts try the runtime-preferred SDK first and fall back to the other when the import fails. Bun-compiled hosts (omp) that misdetect as bun and choke on @ff-labs/fff-bun's TS entry now transparently fall back to the JS-compiled @ff-labs/fff-node. Adds test/sdk.test.ts covering candidate selection, fallback, and last-error rethrow. Not yet merged.

Honk-Honk 🪿

[dmtrKovalenko]

Had to figure out installatin process but it works just fine on my end

[elv1n]

OMP can't resolve dynamic import when using FFF as a replacement for file search. FFF mcp is working for agent, but replacing OMP's file search with FFF breaks the module

 Error: FFF init failed: Cannot find package '@ff-labs/fff-bun' imported from                   
 /Users/ko/.config/omp/plugins/node_modules/@ff-labs/pi-fff/src/sdk.ts?mtime=1787695353675  

[negoro26]

Confirming this from the omp side with a root cause, plus a cheaper fix proposal than #779's try/catch fallback.

I traced it through omp's loader source (legacy-pi-compat.ts). The rewriter that absolutizes extension imports only sees string-literal specifiers (collectExtensionSpecifierReferences records a reference solely for StringLiteral arguments). I verified with the __rewriteLegacyExtensionSourceForTests seam: the static import type gets rewritten, import(pkg) passes through untouched, and the compiled runtime then cannot resolve the bare specifier from the ?mtime-tagged importer. omp reviewed this as their issue #10857 and closed it wontfix: on the compiled binary there is no resolve-time fallback possible, so anything not statically visible can never load.

That makes the fix necessarily fff-side, and there is a one-line shape that keeps the lazy isomorphic loading from #668 while becoming statically rewritable — dynamic import with literal arguments instead of a variable:

sdkPromise =
  detectRuntime() === "bun" ? import("@ff-labs/fff-bun") : import("@ff-labs/fff-node");

Both edges stay lazy (neither backend loads until chosen), but both specifiers are now StringLiterals, so omp's rewriter — and any bundler doing static analysis — can resolve them ahead of time. This avoids #779's throw-then-catch roundtrip entirely: nothing fails first.

Workaround until then, confirmed working: drop the pi extension under omp, use the fff MCP server instead.