Upgrade LiveKit dependencies

[kraenhansen]

Summary

• Upgrade direct LiveKit dependencies to current stable versions that satisfy the repo's 7-day release-age policy:
  • livekit-client to ^2.21.0
  • @livekit/react-native to ^2.12.0
  • @livekit/react-native-expo-plugin to ^1.0.2
  • @livekit/react-native-webrtc to ^144.1.2
• Rebased onto current main and reverted the temporary compatibility changes from Fix WebRTC connection by pinning livekit-client to 2.16.1 #782 now that the service is on LiveKit server 1.12.0:
  • remove the exact livekit-client@2.16.1 pin
  • remove singlePeerConnection: false from Room construction
• Remove the local livekit-client patch file/registration and regenerate pnpm-lock.yaml without patch metadata (see below — the patch was unrelated to Fix WebRTC connection by pinning livekit-client to 2.16.1 #782).
• Fix an ambient TextEncoder type in packages/client/src/runtime.ts: LiveKit 2.21.0 tightened LocalParticipant.publishData() to require Uint8Array<ArrayBuffer> (NonSharedUint8Array), but the project's runtime-agnostic shim declared encode() as returning the wider Uint8Array<ArrayBufferLike>, which no longer type-checked.

Why removing patches/livekit-client@2.16.1.patch is safe

The patch did not come from #782 (that PR only renamed it when changing the pin) — it came from #556, fixing a convai-widget crash on Wix sites: Wix's security hardening makes EventTarget.prototype.addEventListener non-writable, and wrapPeerConnectionEvent in the webrtc-adapter code bundled inside livekit-client crashed with a strict-mode TypeError when assigning proto.addEventListener. The patch guarded that assignment.

That fix has since landed upstream: #556 filed webrtcHacks/adapter#1177, fixed by adapter#1178 (merged 2026-04-16). The livekit-client@2.21.0 bundle contains the fixed guard — wrapPeerConnectionEvent now returns early when Object.getOwnPropertyDescriptor(EventTarget.prototype, 'addEventListener').writable is false, which checks exactly the property Wix hardens, with the same graceful degradation as our patch (skip the polyfill, log).

Validation

• pnpm install
• pnpm turbo build check-types lint test (all 34 tasks pass, including the disconnect-consistency regression tests from Fix conversation state consistency through disconnect #925 running against 2.21.0)
• Verified the WebRTC conversation flow end-to-end in the React Native example on a physical Android device (connect, converse, disconnect)

Slack Thread

---

Note

Medium Risk
Touches core WebRTC connection setup and dependency versions for voice transport; behavior change from dropping the dual-peer workaround depends on server compatibility, though validation and upstream fixes reduce regression risk.

Overview
Bumps LiveKit across the monorepo: livekit-client to ^2.21.0, React Native packages to ^2.12.0 / ^144.1.2 (plus Expo example plugin ^1.0.2), with lockfile refresh and no more exact 2.16.1 pin.

Reverts temporary server compatibility from #782: WebRTCConnection now uses new Room() without singlePeerConnection: false, assuming LiveKit server 1.12.0 supports the v1 join path.

Removes patches/livekit-client@2.16.1.patch and patchedDependencies registration; upstream livekit-client now includes the Wix/non-writable addEventListener guard that the patch provided.

Aligns TextEncoder.encode in runtime.ts to return Uint8Array<ArrayBuffer> so publishData type-checks against LiveKit 2.21.0.

^{Reviewed by Cursor Bugbot for commit 78d7219. Bugbot is set up for automated code reviews on this repo. Configure here.}

[kraenhansen]

Checked out the branch locally and ran the example which is exhibiting the symptoms from #661 and #766 - we need to solve that first.

[kraenhansen]

It's my current understanding that we're blocked on upgrading the LiveKit SDKs as they introduced changes which aren't backwards compatible with the server, we're currently working on upgrading the server to unblock this upgrade.

[kalvin807]

we might not need the git patch after the bump. (see #532)
upstream fixed the bug livekit/client-sdk-js#1858

[zacharytyhacz]

Is this still in progress?

[kraenhansen]

@kalvin807 can you help me verify that the patch is no longer needed? I agree this seems to be the case (with webrtcHacks/adapter#1177 (comment)) but then this issue popped up 🤔 webrtcHacks/adapter#1194