feat(core): demonstrate aube C ABI (bun:ffi) installer behind Npm.Service

[jdx]

Issue for this PR

References #37301 (demonstration companion to the Node-API variant; not intended to land alongside it)

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Demonstrates the C ABI / bun:ffi flavor of the same Npm.Service swap proposed in #37301: packages/core/src/npm.ts backed by @jdxcode/aube-ffi instead of @npmcli/arborist. This exists so both aube embedding surfaces can be compared side by side against the Node-API PR; the Node-API variant is the one I'd recommend landing.

How it works: aube_wait blocks the thread that calls it, so each operation runs in a Bun Worker (packages/core/src/aube-ffi/worker.ts) that dlopens the library, starts aube_install/aube_add, posts the operation handle back, then blocks in aube_wait and posts the JSON result. The client (aube-ffi/client.ts) maps the Effect scope's AbortSignal to a main-thread aube_cancel on that handle, so the event loop is never blocked and cancellation works. Offline-first policy is identical to the Node-API PR.

Notable differences vs the Node-API variant, from actually building both:

• Raw specifiers pass straight through — aube_add takes an array of spec strings, so git/tarball/alias specs need no name/version splitting (the Node-API input is {name, version} pairs).
• The host owns more glue: the .npmrc omit=dev|optional → dependency-selection mapping that the Node-API addon does internally had to be reimplemented here, and the blocking-wait/worker/cancel choreography is ~150 lines that @jdxcode/aube-node simply doesn't need.
• Bun-only: bun:ffi doesn't exist under Node, so this variant can't back the node build. Progress-event callbacks are also off the table (aube's docs point Bun hosts to Node-API for JS callbacks).
• No compiled-binary story here: the Node-API package ships a bunPlugin for embedding one platform addon per compiled target; doing the same for the FFI dylib would need hand-rolled embed/extract wiring, which I deliberately left out of a demo.

How did you verify your code works?

• Same packages/core suite as the Node-API PR: 31/31 pass, including .npmrc omit=dev and file: spec cases (which exercise the raw-spec pass-through)
• tsc clean for packages/core; oxlint 0 errors; prettier clean
• Live smoke against the real registry: which("prettier") and add("@ai-sdk/openai@latest") resolve; repeated no-op installs are ~6.6 ms in-process (worker spawn dominates; the offline state check itself is sub-millisecond)
• Benchmarks (same harness/machine as the Node-API PR): cold add 775–1531 ms, warm add 587–697 ms, no-op 19 ms per fresh process — within a few percent of the Node-API numbers, as expected for the same engine plus per-op worker spawn

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

---

Written by an AI coding assistant (Claude Code), directed and reviewed by @jdx.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Related PR Found:

• feat(core): use aube-node native installer for runtime package installs #37300 — feat(core): use aube-node native installer for runtime package installs
  • feat(core): use aube-node native installer for runtime package installs #37300

Why it's related: PR #37300 is the Node-API variant companion mentioned in the description of #37305. Both PRs demonstrate alternative Npm.Service implementations using the aube embedding library. The PR description explicitly states this is a "demonstration companion to the Node-API variant" and recommends the Node-API approach (#37300) for landing. These are meant to be compared side-by-side but not landed together.

[jdx]

Closing — the aube adoption will land as a single PR (#37300); this C ABI comparison is no longer needed. This comment was generated by an AI coding assistant.