Browsers compatibility is not the same as for media-chrome

[k-g-a]

Some of the packages (at least media-tracks) are buit for relatively modern browsers (in contrast with media-chrome, which is built with --target=es2019 option). Moreover the custom-video-element sub-package is not built at all.

This leads to some features (i.e. private fields) being kept within distributed packages.
This, in turn, leads to errors on the end-user side when used with an old browser (i.e. Safari 14).

The only solution for now is to re-transpile those packages within the consuming application.

The proposed solution is to add --target=es2019 option to match the media-chrome build target.

[luwes]

Thanks for bringing this issue up!

So far for our use case it's not a problem I believe because media-tracks and custom-media-element are meant to be imported in a custom media and rebuild. Are you running into this problem yourself?

[k-g-a]

Hi, @luwes!

Yes, we did ran into this problem after enhancing our internal media player (built upon hls.js + media-chrome) with both of those packages.

You are absolutely right that it's not a big deal and one can easily transpile those dependencies to any target within it's own library/application. So did we right after the first logged unhandled exception :)

But the point is that we just did not expect libraries coming from the same "vendor" and based on the same concepts to have substantial difference in browser support.

Perhaps we could just mention it somewhere in readme for the further consumers to have a lesser chance to face the same issue?