build(livekit-uniffi): keep uniffi cli out of shipped library builds#1275
build(livekit-uniffi): keep uniffi cli out of shipped library builds#1275jhugman wants to merge 1 commit into
cli out of shipped library builds#1275Conversation
Changeset incompleteThis PR's changeset is missing version bumps for packages that are affected by the change. The following packages still require a bump:
Already covered:
A package must be bumped when its own files change, and whenever a package it depends on is bumped (so downstream consumers get a matching release). Click here to create a changeset for the missing packages The link pre-populates a changeset file with If this change doesn't require a version bump, add the |
7f4f403 to
c89c22d
Compare
c89c22d to
a320279
Compare
The uniffi `cli` feature (clap + the bindings backends) is only needed by the `uniffi-bindgen` bin, but it was a hard dependency feature — so it was compiled into every library build of the shipped cdylib/staticlib, and was also pulled in transitively through livekit-datatrack's `uniffi` feature. Gate it behind an opt-in `cli` feature with `required-features` on the bin (mirroring the existing `dart-bindgen` pattern), drop the spurious `cli` from livekit-datatrack (a plain library that never calls the bindgen CLI), and pass `--features cli` in the Makefile bindgen task. Bindgen already runs in library mode against the compiled cdylib, so it stays fully decoupled. Removes clap + the bindgen backends (~43 MiB) from the static archive and cuts crate compile time ~3x. The LTO'd shipped dylib already dead-stripped the unreachable cli code, so the dynamic artifact is byte-unchanged.
a320279 to
3c21c3d
Compare
| --- | ||
| livekit-uniffi: patch | ||
| --- |
There was a problem hiding this comment.
🟡 Changeset omits the second crate modified in this change
The changeset only lists one package (.changeset/remove_uniffi_cli_from_staticlib.md:2) even though this change also edits the data-track package's build settings, so the release tooling won't record or version that package's change.
Impact: The modified data-track package may ship without its change being documented or versioned, contrary to the project's changeset requirement.
Changeset requirement vs. modified files
The repository's AGENTS.md states: "Changeset must list any crates which need to be bumped stemming from the change." This PR modifies livekit-datatrack/Cargo.toml:24 (removing the cli feature from the optional uniffi dependency), which alters what livekit-datatrack compiles when its uniffi feature is enabled. livekit-datatrack is a versioned, published crate (livekit-datatrack/Cargo.toml:4, version 0.1.11), yet the changeset at .changeset/remove_uniffi_cli_from_staticlib.md only lists livekit-uniffi: patch. Consider adding a livekit-datatrack: patch entry.
Was this helpful? React with 👍 or 👎 to provide feedback.
The uniffi
clifeature (clap + the bindings backends) is only needed by theuniffi-bindgenbin, but it was a hard dependency feature — so it was compiled into every library build of the shipped cdylib/staticlib, and was also pulled in transitively through livekit-datatrack'suniffifeature.Gate it behind an opt-in
clifeature withrequired-featureson the bin (mirroring the existingdart-bindgenpattern), drop the spuriousclifrom livekit-datatrack (a plain library that never calls the bindgen CLI), and pass--features cliin the Makefile bindgen task. Bindgen already runs in library mode against the compiled cdylib, so it stays fully decoupled.Removes clap + the bindgen backends (~43 MiB) from the static archive and cuts crate compile time ~3x. The LTO'd shipped dylib already dead-stripped the unreachable cli code, so the dynamic artifact is byte-unchanged.
Before you submit your PR
Make sure the following is true before submitting your PR:
PR description
Describe the changes in this PR. Explain what the PR is meant to solve and how to reproduce the issue in the first place.
Breaking changes
If this PR introduces breaking changes, list them here and document the rationale for introducing such a change.
MSRV
If the PR modifies the crate's MSRV (Minimum Supported Rust Version), document it here.
Testing
Ideally, unit test the code you add, but ensure you're not repeating existing test cases. Use as many already written scaffolding, utilities as possible; write your own, when needed. If external services, APIs, tokens are required (e.g., running an LK server instance), provide the necessary information. Make sure your tests perform useful, context-aware assertions and do not simply emulate "happy paths".
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.