Allow semver range for @livekit/protocol

[Philzen]

Harmonizing it with livekit-server-sdk, allowing for a semver range so package managers can resolve to a single compatible version instead of two (which is currently the case).

Hence i'd like to re-raise this, to save consumers from having to manually dedupe their dependencies each time.

For further information, see #1356 (comment) and #1356 (comment)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 76c9cf5

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[lukasIO]

we're relying on exact versions within the SDK implementation, we don't want to support a range for that reason, sorry.

[Philzen]

we're relying on exact versions within the SDK implementation, we don't want to support a range for that reason, sorry.

I hear you – so if the protocol follows semver, using an exact minimum version would suffice, wouldn't it? Alas, a minimum version range seems to work fine for https://github.com/livekit/node-sdks/blob/a1d26a149340535b132b6360d397f01cd6bd374c/packages/livekit-server-sdk/package.json#L45, why wouldn't it be for livekit-client SDK?

Would just like to understand this better. This may also have implications on the feasibility / stability of a manual dedupe.

[lukasIO]

the protocol repo doesn't strictly follow semver.

Secondly, and more importantly, the issue you're running into is one of type mismatch.
this repo bundles all dependencies at build time. The range specified in package.json has no effect on this at all.
Historically this used to be different for livekit-server-sdk (it only transpiled from ts to js without a bundling step) hence a range could have made more sense if the goal ever was to dedupe dependencies.