Hls.js: Provide an ES Modules build for modern browsers/tools

[alangdm]

Is your feature request related to a problem? Please describe.

This is a more detailed follow up to this comment I made on the 1.0.0 issue https://github.com/video-dev/hls.js/issues/2861#issuecomment-659885729

hls.js's dist build currently only provides UMD builds for the different entry points and these are necessary to provide IE support by default.

However, providing an extra es modules build for all entry points would have the following benefits:

• All modern browsers could load the es modules builds directly from a CDN using <script type="module">. This includes around 91% of all internet users
• ES Modules builds include far less polyfills and are more easily tree-shakeable so apps using them could have between 10-30% decreases in hls.js bundle code
• Some modern build tools like rollup, vite, or snowpack either don't support non-standard modules or only support them through extra plugins

Describe the solution you'd like
Provide es modules versions of all dist bundles and update the docs to suggest using those instead of the UMD modules if possible.

As for the names, the easiest way would be to add an .esm suffix to all the new files e.g. hls.esm.js, hls.light.min.esm.js, etc.

Describe alternatives you've considered
Considering that real es modules output support in webpack won't be included until v5, these are the approaches I was able to come up with to tackle this issue:

1. Migrate to Webpack 5: this would arguably be the easiest path, however, Webpack 5 is still in beta so it would probably be wise to wait until it's properly released if this approach is taken.
   Pros: easy path of migration
   Cons: es modules support release would require waiting until webpack 5 officially released
2. Migrate completely to a different build tool that supports es modules output: Replace webpack completely with rollup or other build tool that supports es modules output
   Pros: Keeps a single build tool for the whole library
   Cons: Requires reconfiguring all older build outputs plus adding all the new ones and testing that everything keeps working normally
3. Migrate partially to a different build tool that supports es modules output: Keep using webpack for the UMD build and just use a second tool for the es modules build
   Pros: Only adds the new build configurations
   Cons: Some parts like the use of 'webworkify-webpack' on demuxer might not work on the new tool and viceversa so this solution might not be feasible at all

Additional context
I created a small proof of concept of how a rollup es modules build would work using basically the same babel config as the current webpack config.
https://github.com/alangdm/hls.js/compare/master...esm-build
I can create a draft PR if that makes it easier to check

Before committing on trying to create a full on PR following one of the approaches mentioned above I would like to hear what everyone else thinks regarding this issue.

Thanks a lot for your attention and for the amazing job you've been doing with this library.

[itsjamie]

Thank you for the detailed options @alangdm 💯

@robwalch, what are your thoughts? I think this is important, but we're probably stretched pretty thin as far as bandwidth at this time, and waiting until Webpack 5 would probably work pretty well.

[robwalch]

I'm a fan of rollup, especially since we're not doing code splitting or bundling of assets like css which is the main attraction in webpack. Even doing the UMD in rollup would drop some webpack boilerplate. But v5 could change that.

In terms of timing and priority - for me - this would be a post v1.0 task. I'm open to review and merge updates against master if they improve the build and package output, well before v1 if someone wants to own this.

https://github.com/alangdm/hls.js/compare/master...esm-build Looks like a good start, I just wouldn't want to maintain both bundlers.

@alangdm Did you update webpack and keep it in to compare output?

[alangdm]

@robwalch

I didn't really touch the webpack config, my linter just automatically changed the indentation one time I was checking it for reference 😅

I'm willing to try creating a rollup or webpack v5 config for both the UMD and ES modules build, it seems that you think the rollup config I started working on makes sense so I could keep going with that and see if everything works properly

[tjenkinson]

Rollup with both a UMD and ES output (that could be pointed at from module in the package.json) sounds great to me.

[alangdm]

Just a heads up on this

I sadly haven't had time to dedicate to work on the rollup config

However, it seems that Webpack 5 is finally about to release
https://github.com/webpack/webpack/issues/11406

According to that issue a RC should be out in a couple weeks at most and they're aiming for an October 10th release, so I think it might be worth to try and see if the migration path and the creation of the es modules build is easier with webpack 5 than with rollup

[AradAral]

Any updates on this?