feat(fff-bun): recognise FreeBSD as a platform - #824
Conversation
On FreeBSD the package is unusable for two independent reasons, neither
of them in the Rust code — `cargo build --release -p fff-c` builds
crates/fff-c into a working libfff_c.so on FreeBSD as-is.
1. package.json's "os" list omits freebsd, so bun and npm skip
installing the package entirely. A consumer importing it just gets
"Cannot find module '@ff-labs/fff-bun'".
2. getTriple() throws "Unsupported platform: freebsd". It is reached
from getNpmPackageName(), which resolveFromNpmPackage() calls
*outside* its try/catch, so the throw escapes findBinary() instead of
degrading to "no prebuilt available, fall back to the dev build".
The fallback path exists and works; it is simply never reached.
The two triples added to TRIPLE_TO_NPM_PACKAGE point at
@ff-labs/fff-bin-freebsd-{x64,arm64}, which are not published. That is
harmless: resolveFromNpmPackage() swallows the resolution failure and
findBinary() continues to the locally built library. Publishing those
packages later makes the mapping live with no further code change.
Verified on FreeBSD 15.1 (amd64, bun 1.4.0, rustc 1.96.1): libfff_c.so
loads through bun:ffi, and FileFinder.create() + fileSearch() return
real results with git status and file metadata over a live tree.
aarch64-unknown-freebsd is mapped but was not built or tested.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughChangesFreeBSD support
Estimated code review effort: 2 (Simple) | ~5 minutes Merge Risk: ⚪ Minimal · up to The change adds FreeBSD support for the intended x64 and arm64 platforms while keeping unsupported arm installs excluded. No actionable merge-blocking risk remains. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files. (1 skipped: 1 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
aarch64 update — the PR said FreeBSD 14.4-RELEASE-p5 arm64, rustc/cargo 1.94.0, this branch checked out as-is: And it loads — No Rust changes were needed for arm64, same as for amd64 — Being precise about what this does and does not show: this patch is JS-only ( The 61 minutes is emulation overhead, not something about the code: this is qemu emulating aarch64 on an x86 host, roughly 12x slower than native by wall clock. |
|
@gustav-fff do we provide precompuled binaries for FreeBSD? I do not remember but I doubt it |
|
[triage-bot] DIRECTED: No. There are zero FreeBSD prebuilts, in any channel.
So Making it real needs |
|
@gustav-fff is right, and the caveat is a fair hit on my wording — I checked it against the code rather than taking it on faith:
So for an npm-installed FreeBSD consumer this PR moves the failure from "package refuses to install / cannot find module" to "package installs, Two ways to close the remaining gap, both small enough that I am happy to do either — your call on whether it is worth carrying: A. An env override, no CI cost. Something like B. Real prebuilts. As noted there is no GitHub-hosted FreeBSD runner. Two workable routes: If you would rather not take on B, I can also just drop the two |
3 participants
Summary
Two small changes so
@ff-labs/fff-buncan be used on FreeBSD. The Rust side needs nothing —cargo build --release -p fff-cbuildscrates/fff-cinto a workinglibfff_c.soon FreeBSD exactly as-is. This is purely the JS platform plumbing.The two blockers
1.
package.json"os"omitsfreebsd, so bun/npm skip installing the package altogether. A consumer importing it gets:2.
getTriple()throws before any lookup can happen. It is called fromgetNpmPackageName(), whichresolveFromNpmPackage()invokes outside itstry/catch:So
Unsupported platform: freebsdescapesfindBinary()entirely, instead of degrading to "no prebuilt for this platform, fall through to the dev build". The dev-build fallback already exists and works fine — it is just never reached.About the unpublished package names
The two triples added to
TRIPLE_TO_NPM_PACKAGEpoint at@ff-labs/fff-bin-freebsd-{x64,arm64}, which do not exist on npm. This is deliberate and harmless:resolveFromNpmPackage()catches the resolution failure andfindBinary()moves on to the locally built library. If you ever publish those packages the mapping goes live with no further code change.The alternative — wrapping
getNpmPackageName()in a try/catch at the call site — would also work and would not name unpublished packages. Happy to switch to that if you prefer it; I went with the mapping because it keeps the "which platforms exist" knowledge in one table.Verification
FreeBSD 15.1-RC2, amd64, bun 1.4.0, rustc 1.96.1:
cargo build --release -p fff-c→target/release/libfff_c.so, unpatched.findBinary()resolves it,dlopensucceeds throughbun:ffi.FileFinder.create({ basePath })+waitForScan()+fileSearch()return real results — 100 hits over a live tree, withrelativePath,fileName,gitStatus,size,modifiedall populated correctly.Not covered
packages/fff-node/src/platform.tshas the sameUnsupported platformthrow at line 24 and presumably needs the same treatment, but I only exercised the bun package, so I left it alone rather than ship an untested change. Say the word and I will mirror it.aarch64-unknown-freebsdis mapped but was not built or tested — drop that line if you would rather not carry an unverified target.Context
This came from getting a Bun-based coding agent running on FreeBSD; fff was the first of three native dependencies to need attention, and the only one where the native code itself was already fine.
Summary by CodeRabbit