livekit-client should export TrackType for seamless communication with livekit-server-sdk backend

[Philzen]

Describe the bug

Following the discussion at #1355 (comment) i went ahead and tried to replace TrackType (imported from the transitive dependency @livekit/protocol which following this comment should be discouraged / not necessary) with Track.Kind or Track.Source and came to realize that this is not viable for us.

Explanation

Our backend implements a service – which maps type-safe as a GraphQL-mutation to the frontend – like this:

export const muteParticipant = async ({ input: { roomName, identity, type } }) => {
  try {
      const participant = await roomServiceClient.getParticipant(urlName, identity)

      // select tracks to mute by `TrackType.AUDIO` or `TrackType.VIDEO` ↓
      const tracks = participant.tracks.filter((track) => track.type === type)
      for (const track of tracks) {
        await roomServiceClient.mutePublishedTrack(urlName, identity, track.sid, true)
      )
    } catch (e) {...}
}

Evaluating the possible alternatives to TrackType here:

1. AFAIK the only alternative to track.type here is track.source – but that is not what we want here, as – compared to TrackType the TrackSource type is less deterministic (i.e. it has TrackSource.UNKNOWN which we wouldn't known how to handle here) and also the source of the track is not relevant to this mutation at all.
   ⚠️ Also – Track.Source in livekit-client does not map to TrackSource from livekit-server-sdk/protocol at all … it's actually a pitfall, b/c the former is an enum mapping to string values, while the latter is an enum mapping to integers.
   We could use Track.sourceToProto(s: Source) here, but that is an internal method and also seems more complex than necessary.
2. TrackKind doesn't seem exposed at this point at all – but even if it was, it bears the same caveat regarding type mismatch than above – Track.Kind from livekit-client is a string-enum, while TrackKind from livekit-server-sdk is integer-based. Again, it also has Track.Kind.Unknown (TrackKind.UNKNOWN) respectively, which we don't exactly know what to make out of it.
   Again, Track.kindToProto(k: Kind) could be used in livekit-client, but i don't believe that's an option that the designers of the SDK would want to encourage.
3. last option would be to split the service into dedicated muteParticipantAudio({roomName, identity}) and muteParticipantVideo({roomName, identity}) services. While this seems a clear straightforward solution it effectively duplicates everything on top of the service layer: the generated type code, the gql query code, the mutation callbacks, which is why the current solution is preferable.
4. another option (that is the worst practice imaginable) is to duplicate the type on the front-end – which is actually what we did in LiveKit v1 and were happy to find that LiveKit v2 now has a common base in @livekit/protocol

Summing up, it looks like simply exporting TrackType from livekit-client seems the most straightforward and easiest measure to ensure seamless interop between livekit-client and livekit-server-sdk.

Of course, happy to learn if there's an option i have overlooked here.

Reproduction

_

Logs

No response

System Info

System:
    OS: Linux 6.12 Manjaro Linux
    CPU: (4) x64 Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
    Memory: 2.05 GB / 7.64 GB
    Container: Yes
    Shell: 5.2.37 - /bin/bash
  Binaries:
    Node: 20.16.0 - /run/user/1000/fnm_multishells/2438_1736723076355/bin/node
    Yarn: 4.5.1 - /run/user/1000/fnm_multishells/2438_1736723076355/bin/yarn
    npm: 10.8.1 - /run/user/1000/fnm_multishells/2438_1736723076355/bin/npm
    bun: 1.1.43 - /usr/bin/bun
  Browsers:
    Chromium: 131.0.6778.264

Severity

serious, but I can work around it

Additional Information

No response

[Philzen]

As a suggestion i created #1370.

However i would understand if the livekit core team would refrain from exposing more types from @livekit/protocol to reduce confusion for the time being.

I'm wondering though: what is the concrete reason that livekit-client duplicates all these types from the protocol package (TrackType vs. Track.Type, TrackSource vs. Track.Source, TrackKind vs. Track.Kind and StreamState vs. Track.StreamState).

IMHO it would be preferable to only rely on the types from @livekit/protocol – would make the package smaller, reduce potential confusion and most importantly promote seamless interop with other SDKs. Maybe something worth considering as a breaking change for livekit SDKs v3?

[Philzen]

@davidzhao @momenthana thanks for merging #1370, which solves our issue for the time being.

I'm wondering though: what is the concrete reason that livekit-client duplicates all these types from the protocol package (TrackType vs. Track.Type, TrackSource vs. Track.Source, TrackKind vs. Track.Kind and StreamState vs. Track.StreamState).

Just BTW – ConnectionState from @livekit/protocol (int enum) vs. ConnectionState from livekit-client (string enum) is another one of these "false friends" and should be included in this list.

IMHO it would be preferable to only rely on the types from @livekit/protocol – would make the package smaller, reduce potential confusion and most importantly promote seamless interop with other SDKs. Maybe something worth considering as a breaking change for livekit SDKs v3?

Would be keen to follow up on this point and learn the LiveKit SDK teams' take on these.