Fix native sharp embedding so macOS (and other targets) can build#1
Merged
xjdr-noumena merged 1 commit intoJun 18, 2026
Conversation
The sharp shim statically imported the linux-x64 and linux-x64-musl
`@img/sharp-*` native assets via `import ... with { type: 'file' }`.
Bun only installs the `@img/sharp-*` optional dependencies matching the
build host's os/cpu, so on macOS those Linux files are absent and the
bundler fails to resolve them, aborting both `bun run build` and
`bun run build:source`. This broke the macOS "build from source" path
that OSS_BUILD.md documents as supported.
Make the embedding target-aware instead of Linux-only:
- Add darwin asset shims (sharpDarwinArm64.ts, sharpDarwinX64.ts).
- Add per-target bindings (sharpBinding.darwin-arm64.cjs,
sharpBinding.darwin-x64.cjs); each only imports its own platform's
assets, since no single host has every platform's packages installed.
- Extract the shared materialize-and-load logic into
loadEmbeddedSharp.cjs; the linux binding now uses it (behavior
unchanged).
- Select the binding per compile target in build.mjs, defaulting to the
build host for source/standalone builds.
- Ignore Bun's *.bun-build compile intermediates.
Verified: `bun run build` produces a working ncode-darwin-arm64 binary,
and a standalone probe confirms the embedded darwin sharp addon loads
libvips through its @loader_path rpath at runtime.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
|
This looks fine, i will most likely merge once i can test. i am setting up MacOS and Windows build and test clusters this week. stay tuned |
Contributor
|
merged, thank you again for the PR! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
bun run buildandbun run build:sourcefail on macOS with:The sharp shim (
src/shims/sharp/sharpBinding.cjs) statically imports the linux-x64 and linux-x64-musl@img/sharp-*native assets viaimport … with { type: 'file' }. Bun only installs the@img/sharp-*optional dependencies that match the build host'sos/cpu, so on macOS (and Linux arm64, etc.) those Linux files are absent and the bundler aborts.This breaks the macOS "build from source" path that
OSS_BUILD.mdlists as supported. The build had effectively only ever worked on linux-x64.Fix
Make the native sharp embedding target-aware instead of Linux-only:
src/shims/assets/sharpDarwinArm64.ts,sharpDarwinX64.ts.sharpBinding.darwin-arm64.cjs,sharpBinding.darwin-x64.cjs. Each binding only imports its own platform's assets — no single build host has every platform's@imgpackages installed, so an all-platforms shim can never bundle anywhere.loadEmbeddedSharp.cjs; the existing linux binding now uses it. Linux behavior is unchanged.build/build.mjs, select the sharp binding per compile target (linux-x64,linux-x64-musl,darwin-arm64,darwin-x64), defaulting to the build host for source/standalone builds.*.bun-buildcompile intermediates.Verification
On macOS arm64:
bun run buildnow completes →.tmp/packages/ncode-0.1.0-darwin-arm64/ncode.ncode --version→0.1.0 (NCode),ncode --helpworks.dlopens libvips through its@loader_pathrpath at runtime (the darwin.noderesolves@rpath/libvips-cpp.8.17.3.dylibvia@loader_path/../../sharp-libvips-darwin-arm64/lib, which matches the materialized layout).bun test src/shims/nativeAssetRuntime.test.tspasses.The linux-x64 / linux-x64-musl code path is untouched apart from the shared-loader refactor.
Notes
rustc 1.87 … napi-build requires 1.88warnings during the build are non-fatal (the build continues with JS/SSE fallbacks) and are out of scope here.🤖 Generated with Claude Code