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

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/[email protected])
• 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.