Switch node support from uniffi-bindgen-node to uniffi-bindgen-react-native. - #1374
Open
jhugman wants to merge 4 commits into
Open
Switch node support from uniffi-bindgen-node to uniffi-bindgen-react-native.#1374jhugman wants to merge 4 commits into
jhugman wants to merge 4 commits into
Conversation
Contributor
Changeset ✓This PR includes a changeset covering all affected packages:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Note
This report is out of date. Scroll down for Devin Review's latest report on this PR.
🔍 Devin Review: 1 flag
Not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)
jhugman
marked this pull request as draft
August 28, 2026 17:47
jhugman
force-pushed
the
jhugman/switch-to-ubrn
branch
from
September 1, 2026 15:50
279b297 to
84e0391
Compare
Generates NAPI TypeScript bindings from any compiled uniffi cdylib, so it sits alongside the uniffi-bindgen already here rather than being vendored into one crate's build. `default-features = false` is load-bearing, not tidiness: ubrn's `wasm` feature pulls wasm-bindgen-cli-support, which `=`-pins the wasm-bindgen family to its own version — unsatisfiable against the wasm-bindgen this workspace resolves through livekit -> libwebrtc. Pinned by commit rather than tag: this is the released line's main, which carries #453 — without it a non-wasm build silently generates JSI bindings instead of NAPI, exit 0 and no warning. Move to a tag when one ships past 0.31.0-5. A `rev` also keeps `cargo update` from sweeping the generator forward on its own, since what it emits has to stay in step with the @ubjs/* runtime it imports.
jhugman
force-pushed
the
jhugman/switch-to-ubrn
branch
from
September 1, 2026 17:00
84e0391 to
645ddcc
Compare
…ative Replaces uniffi-bindgen-node and its download-at-install shim with ubrn's NAPI backend and the prebuilt-sibling layout the node ecosystem already uses: `@livekit/uniffi` carries the TypeScript and declares one optional dependency per platform, and `@livekit/uniffi-<triple>` carries just the cdylib. @ubjs/node resolves the right sibling at load time, so nothing downloads a library on install. The node flow owns more tasks than any other language here and reads badly inline, so it lives in support/node/Makefile.node.toml beside the files it drives. cargo-make resolves `extend` relative to the crate Makefile and runs everything from the crate root, so paths there are written as if they were here. Two things worth knowing about the tasks: - Bindgen builds unstripped and packaging builds stripped, each on its own wrapper task. ubrn reads uniffi metadata out of the library's symbols; what ships must match the profile uniffi-cdylib.yml builds with. cargo-make env persists process-wide, so a single run doing both needs each setting re-asserted at its own step. - livekit_uniffi's cdylib bundles several uniffi namespaces into one physical library, and ubrn emits one `*-ffi.ts` per namespace, each resolving by its own `crateName` — every one of them pointing at a dylib that doesn't exist. node-fixup-crate-name rewrites them to the umbrella crate, and fails loudly if it matches nothing, since silence there means bindings that resolve nowhere. Two tests, both under support/node. node-package-test does the full FFI round trip against the built workspace, in CJS. node-pack-test installs the packed tarballs — which is what npm uploads — so `files`, `exports`, and the platform-package lookup all run for real, in ESM; a workspace link goes through none of the three.
Builds the packages for the host triple and runs both tests: the FFI round trip against the built workspace, and the tarball install that stands in for a published consumer. Between them the exports map is covered both ways. Also asserts the generator and the @ubjs/* runtime agree. The bindings are emitted by the generator Cargo.lock pins but import @ubjs/core at a version the manifest template carries; if those drift the package builds fine and fails at load time in a consumer, so the check compares what actually ran against what it actually produced. Not published yet — uniffi-packages.yml says what to add when it is.
The linux cdylibs linked against whatever glibc the runner shipped, which is newer than Debian 12, Ubuntu 22.04, Amazon Linux 2023, or node:*-slim — so a library built here failed to load on the images most consumers deploy to. `--target <triple>.2.28` states the floor instead of inheriting it. zig is also the cross-linker, so aarch64 builds on the x64 runner and the separate arm runner goes away. .cargo/config.toml forces -fuse-ld=lld for aarch64; that reaches `zig cc`, which accepts it.
jhugman
force-pushed
the
jhugman/switch-to-ubrn
branch
from
September 2, 2026 13:39
645ddcc to
554f001
Compare
jhugman
marked this pull request as ready for review
September 2, 2026 14:32
Contributor
There was a problem hiding this comment.
Devin Review found 2 new potential issues.
1 flag not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)
| PACKAGES_DIR = "./packages" | ||
| SUPPORT_DIR = "./support" | ||
| LIB_NAME = "lib${CARGO_MAKE_CRATE_FS_NAME}" | ||
| PACKAGES_DIR = "${CARGO_MAKE_CRATE_TARGET_DIRECTORY}/packages" |
Contributor
There was a problem hiding this comment.
🔴 Non-Node package outputs disappear
Setting PACKAGES_DIR to the workspace target relocates every Swift, Android, and Dart output. Existing workflows and Gradle still read the old directory.
Prompt for agents
The global PACKAGES_DIR change in livekit-uniffi/Makefile.toml moves every language's generated packages from livekit-uniffi/packages to the workspace target/packages directory. Update all consumers consistently, including .github/workflows/uniffi-swift.yml OUTPUT_DIR, .github/workflows/uniffi-dart-test.yml working-directory, and support/android/build.gradle.kts generatedKotlinDir, or scope the target-directory output only to the Node tasks while preserving the existing location for Swift, Android, Kotlin, and Dart.
Was this helpful? React with 👍 or 👎 to provide feedback.
Comment on lines
+41
to
+46
| "optionalDependencies": { | ||
| "{{ NPM_NAME }}-darwin-arm64": "{{ CARGO_MAKE_CRATE_VERSION }}", | ||
| "{{ NPM_NAME }}-darwin-x64": "{{ CARGO_MAKE_CRATE_VERSION }}", | ||
| "{{ NPM_NAME }}-linux-x64-gnu": "{{ CARGO_MAKE_CRATE_VERSION }}", | ||
| "{{ NPM_NAME }}-linux-arm64-gnu": "{{ CARGO_MAKE_CRATE_VERSION }}", | ||
| "{{ NPM_NAME }}-win32-x64-msvc": "{{ CARGO_MAKE_CRATE_VERSION }}" |
Contributor
There was a problem hiding this comment.
🟡 Windows ARM64 package disappears
On Windows ARM64, optionalDependencies has no matching package despite the built ARM64 library. Loading @livekit/uniffi therefore loses prior platform support.
Prompt for agents
Restore Windows ARM64 support in the new per-architecture package layout. Add the aarch64-pc-windows-msvc to win32-arm64-msvc mapping in livekit-uniffi/support/node/Makefile.node.toml and declare @livekit/uniffi-win32-arm64-msvc in livekit-uniffi/support/node/package.json.tera. Ensure the native package manifest derives os=win32 and cpu=arm64, and include this target when the package matrix is introduced.
Was this helpful? React with 👍 or 👎 to provide feedback.
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
1 participant
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.
This is largely derived from the AIC work, which publishes to npmjs.