Add dart/flutter bindings to livekit-uniffi#1183
Conversation
ChangesetThe following package versions will be affected by this PR:
|
Release/multi-platform delivery for the Dart package: - uniffi-cdylib.yml builds liblivekit_uniffi for desktop + mobile targets and attaches build-<triple>.zip (+ .sha256) to the livekit-uniffi release; wired into uniffi-packages.yml. Validated across all 10 targets via CI dry-run. - hook/build.dart.tera gains a download mode: fetches and SHA-256-verifies the prebuilt library for the target when no local build is present.
Ship tests in support/dart/test, copied into the generated package by the dart-package flow. Covers the FFI smoke path (buildVersion) and a real JWT/HMAC round-trip (generate -> verify -> decode, plus wrong-secret rejection) to exercise Rust logic across the boundary.
uniffi-dart-test.yml builds the Dart package (host cdylib + bindings via cargo make dart-package) and runs dart test on PRs/pushes touching livekit-uniffi or its dependencies. The dart build keeps symbols (CARGO_PROFILE_RELEASE_STRIP=false) so library-mode bindgen can read the UNIFFI_META_* metadata, which the release strip removes on Linux.
jhugman
force-pushed
the
jhugman/dart-bindings
branch
from
cdd271c to
c60ae51
Compare
1egoman
left a comment
1egoman
left a comment
There was a problem hiding this comment.
A few high level thoughts. I am deferring an official review approval to folks with more first hand flutter experience.
| } | ||
|
|
||
| Future<List<int>> _downloadAndVerify(Uri zipUrl) async { | ||
| final zipResp = await http.get(zipUrl); |
There was a problem hiding this comment.
thought: Does this request have a default timeout? I'm assuming so but it would be worth confirming.
thought: Also, does this http.get follow 3xx redirects properly? If not, I think it would be worth making sure it does, that opens up a lot of future flexibility.
| if (zipResp.statusCode != 200) { | ||
| throw Exception('Failed to download $zipUrl: HTTP ${zipResp.statusCode}'); | ||
| } |
There was a problem hiding this comment.
nitpick: Also in the aim of future flexibility, maybe making this verify 2xx not strictly 200 might be a good idea.
| output.assets.code.add( | ||
| CodeAsset( | ||
| package: input.packageName, | ||
| // Dart prefixes this with `package:<packageName>/`. | ||
| name: 'uniffi:$_cdylibName', | ||
| linkMode: DynamicLoadingBundled(), | ||
| file: libFile, | ||
| ), | ||
| ); |
There was a problem hiding this comment.
thought: An interesting related blog post I came across in my research: https://www.simonbinder.eu/posts/native_assets/
I'm not sure how much of this applies since this is a net new package, but the thing that stood out to me was that it seems like by using native assets (I think that's what you are doing here?) you potentially force consumers to also enable the native assets feature. Maybe that's fine but could be problematic once this gets folded into the dart sdk and could maybe break existing users
(Feel free to ignore this if it's not relevant, you're probably done more research into dart packaging than I have at this point)
2 participants
Before you submit your PR
Make sure the following is true before submitting your PR:
PR description
Added Dart bindings with the uniffi-dart bindgen. This generates a
Native AssetsAPI. Exercise withcargo make bindgen-dart.This adds a uniffi-bindgen-dart feature to the
livekit-unifficrate: followup would be to separate out the uniffi-tooling binaries in to a workspace centred tooling crate.Added consumable package, with a hook/build.dart. This works both locally, and by downloading a prebuilt cdylib.
Added CI which builds the cdylibs per OS/architecture on release.
Breaking changes
No changes breaking changes are made, however:
uniffi-dartbindgen needed a bug fix which means the version of uniffi-dart is from main (pinned to the hash).uniffi-bindgen-node. Followup: moveuniffi-bindgen-nodetouniffi-bindgen-react-native.MSRV
No changes. uniffi 0.31 requires >= 1.85
Testing
support/dart/tests): a smoke test including a negative case.Async
We want the project to be runtime-agnostic, so please reuse what's already in livekit-runtime and feel free to add anything missing. It's ok to use Tokio directly, when writing unit tests, if necessary. When testing, do not use artificial delays for the state to "catch up"; instead, respect the event flow and subscribe properly using channels or other mechanisms.