[Bug]: pi-fff 0.10.5 fails to load fff-node: No "exports" main defined

[Whisperfall]

Which fff frontend?

Node SDK (@ff-labs/fff-node)

has logs

No response

Description

pi-fff 0.10.5 fails to load fff-node under Pi

After updating to 0.10.5, FFF fails when initialized inside Pi:

Error: FFF init failed: No "exports" main defined in
/home/altan/.pi/agent/npm/node_modules/@ff-labs/fff-node/package.json

Environment

Pi: 0.84.2
pi-fff: 0.10.5
fff-node: 0.10.5
Node: v24.18.0
Bun: 1.2.20
Linux

I removed and reinstalled the extension from scratch, but the error remained.

I also verified that @ff-labs/fff-node itself appears to be installed correctly:

• dist/index.js exists
• dist/index.cjs exists
• package.json contains a valid "exports"."." entry for both import and require

Direct imports work correctly with both Node and Bun:

cd ~/.pi/agent/npm

node -e "import('@ff-labs/fff-node').then(x => console.log('OK', Object.keys(x))).catch(console.error)"
bun -e "import('@ff-labs/fff-node').then(x => console.log('OK', Object.keys(x))).catch(console.error)"

Both succeed.

A variable dynamic import also works outside Pi:

node -e 'const pkg="@ff-labs/fff-node"; import(pkg).then(() => console.log("OK")).catch(console.error)'

In pi-fff/src/sdk.ts, the package is loaded like this:

const pkg = detectRuntime() === "bun" ? "@ff-labs/fff-bun" : "@ff-labs/fff-node";
const p = import(pkg) as Promise<{ FileFinder: FileFinderStatic }>;

As a test, I changed it to a literal import:

const p = import("@ff-labs/fff-node") as Promise<{ FileFinder: FileFinderStatic }>;

So far this points to the dynamic import being resolved differently when executed through Pi's extension loader, rather than an issue with the published fff-node package itself.

No FFF log file is generated by pi-fff in this setup.

I checked the pi-fff source: FileFinder.create() is called without logFilePath or logLevel, and no fff*.log file exists anywhere under my home directory.

[gustav-fff]

[triage-bot] NEEDS INFO: cannot reproduce on pi 0.84.2 + published @ff-labs/pi-fff@0.10.5.

Tried on macOS arm64, Node v26.7.0 and Node v24.16.0, extension tree installed both with npm and with bun:

mkdir -p /tmp/piroot /tmp/work && cd /tmp/piroot
echo '{"private":true,"dependencies":{"@ff-labs/pi-fff":"0.10.5"}}' > package.json
npm install            # and separately: bun install
cd /tmp/work
pi -e /tmp/piroot/node_modules/@ff-labs/pi-fff/src/index.ts -p --no-session "reply OK"

All three combinations load the extension, register fffind, return results. No resolution error.

The published package is not malformed. @ff-labs/fff-node@0.10.5 exports:

{".":{"types":"./dist/index.d.ts","import":"./dist/index.js","default":"./dist/index.js","require":"./dist/index.cjs"},"./package.json":"./package.json"}

"default" is there, so no condition set can miss ..

That error string is also not Node's. It comes from the resolver vendored into pi's own extension loader — jiti 2.7.0, createJiti(import.meta.url, { moduleCache: false, alias }) at pi-coding-agent/dist/core/extensions/loader.js:358. So the failing resolution happens inside jiti with some wrong parent URL or condition set on your machine, not in the fff-node package.

Need from @Whisperfall before this can be fixed rather than guessed:

1. Full stack trace, not just the message — which file throws.
2. ls -la ~/.pi/agent/npm/node_modules/@ff-labs/ and readlink -f ~/.pi/agent/npm/node_modules/@ff-labs/fff-node — symlink or real dir?
3. Duplicate copy? find ~/.pi/agent/npm -maxdepth 5 -name fff-node
4. How pi itself was installed (npm i -g / bun i -g / other), and which jiti it ends up with: node -p "require.resolve('jiti/package.json',{paths:[require('path').dirname(require('fs').realpathSync(require('child_process').execSync('which pi').toString().trim()))]})"
5. You wrote you swapped in a literal import("@ff-labs/fff-node") "as a test" but never said whether it actually worked. State it plainly — that single data point decides whether the fix is dropping the computed specifier in packages/pi-fff/src/sdk.ts:37.
6. Retest with @ff-labs/pi-fff@0.10.6-nightly.d5b4abd and report.

Honk-Honk 🪿

[Whisperfall]

Thanks. Here is the additional information.

1. Full stack trace

I could not get a full stack trace. Pi only surfaces:

Error: FFF init failed: No "exports" main defined in
/home/altan/.pi/agent/npm/node_modules/@ff-labs/fff-node/package.json

I also started Pi with:

NODE_OPTIONS="--trace-uncaught --trace-warnings" pi

but no additional stack trace was printed when the error occurred.

2. fff-node installation

ls -la ~/.pi/agent/npm/node_modules/@ff-labs/

shows normal directories:

fff-bin-linux-x64-gnu
fff-bun
fff-node
pi-fff

And:

readlink -f ~/.pi/agent/npm/node_modules/@ff-labs/fff-node

returns:

/home/altan/.pi/agent/npm/node_modules/@ff-labs/fff-node

So it is a real directory, not a symlink.

3. Duplicate copies

find ~/.pi/agent/npm -maxdepth 5 -name fff-node -print

returns only:

/home/altan/.pi/agent/npm/node_modules/@ff-labs/fff-node

4. Pi / Node / jiti installation

Pi: 0.84.2
Node: v24.18.0
Bun: 1.2.20
pi-fff: 0.10.5
fff-node: 0.10.5

Pi was installed globally with npm:

/home/altan/.nvm/versions/node/v24.18.0/bin/pi
→ /home/altan/.nvm/versions/node/v24.18.0/lib/node_modules/@earendil-works/pi-coding-agent/dist/cli.js

@earendil-works/pi-coding-agent@0.84.2

Resolved jiti:

/home/altan/.nvm/versions/node/v24.18.0/lib/node_modules/@earendil-works/pi-coding-agent/node_modules/jiti/package.json

Version:

2.7.0

5. Literal vs computed import

I tested replacing:

const p = import(pkg) as Promise<{ FileFinder: FileFinderStatic }>;

with:

const p = import("@ff-labs/fff-node") as Promise<{ FileFinder: FileFinderStatic }>;

The literal import worked.

However, after restoring the original import(pkg), the same ffgrep test also worked. Therefore I cannot confirm that the literal import fixes the problem.

The failure appears intermittent/context-dependent rather than a deterministic failure of import(pkg).

For example, in an existing long-running Pi chat I can get:

ffgrep /2-/ in _bmad-output/implementation-artifacts/sprint-status.yaml

Error: FFF init failed: No "exports" main defined in
/home/altan/.pi/agent/npm/node_modules/@ff-labs/fff-node/package.json

while after restarting Pi, fffind and ffgrep can work normally with the original computed import.

Direct imports outside Pi consistently work:

node -e "import('@ff-labs/fff-node').then(() => console.log('OK'))"
bun -e "import('@ff-labs/fff-node').then(() => console.log('OK'))"
node -e 'const pkg="@ff-labs/fff-node"; import(pkg).then(() => console.log("OK"))'

All return OK.

6. Nightly

I have not tested @ff-labs/pi-fff@0.10.6-nightly.d5b4abd.

Given that the issue is intermittent and currently stopped reproducing after restarting Pi, I don't have a reliable pass/fail reproduction for comparing the nightly build yet.

[gustav-fff]

[triage-bot] CANNOT REPRODUCE: this is a jiti resolver bug in pi's extension loader, not a fff defect.

Your data pins it down:

• @ff-labs/fff-node exports are valid (import/require/default all present) and direct import() under both node and bun always returns OK. Package is not malformed.
• The error string No "exports" main defined is jiti-internal, emitted from pi's loader (createJiti(..., { moduleCache: false }), jiti 2.7.0), not from Node's own resolver.
• It is intermittent and session-scoped: fails only inside long-running pi chats, gone after restart. A malformed package or a broken computed specifier would fail deterministically, every time, from a clean start. This does not.
• Your literal-vs-computed test was inconclusive by your own account (computed import(pkg) also worked after you restored it).

So the failing resolution happens inside jiti with moduleCache: false re-executing the extension graph across /reload, its exports condition resolution going stale over the session. That is @earendil-works/pi-coding-agent + jiti 2.7.0 territory, not packages/pi-fff/src/sdk.ts:38.

The only fff-side change available is dropping the computed specifier at sdk.ts:38 for two literal import() calls, so jiti never has to resolve a runtime string. That removes the suspect path but I will not ship it blind as a fix: your own test could not confirm it helps, and I cannot trigger the failure here to verify. Shipping an unverifiable "fix" for an intermittent third-party-loader bug is worse than leaving it open.

Two things that would move this:

1. A deterministic repro (exact sequence that flips a working session into the failing state). Without it there is nothing to verify a fix against.
2. Report upstream to pi (@earendil-works/pi-coding-agent), jiti 2.7.0, moduleCache: false resolving package exports intermittently in long sessions. That is where the bug lives.

If a maintainer wants the sdk.ts:38 literal-import hardening landed as defensive-only (no repro), say so and I open it, tagging @dmtrKovalenko since it is a jiti workaround, not a real fix.

Honk-Honk 🪿