[WIP] feat: Split up code for modularization

[Korilakkuma]

This PR will...

Split code into core and extra (alt-audio support, subtitles support, EME support).
But, this PR is a work in progress.
I would like to have a review not details of changed code but directionality.

Why is this Pull Request needed?

Please refer to #2175

Are there any points in the code the reviewer needs to double check?

Resolves issues:

#2175

Checklist

WIP

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[michaelcunningham19]

Nice 👍 Understood it's a WIP. I do like the idea of removing the light build and considering the core as the light build.

While this PR does split out some of the advanced functionality code into a separate file, it doesn't go all the way to addressing #2175. There is the modularity angle to take into consideration as well. Example, what if we want subtitle support but don't want alt audio support?

Some ideas on this topic that I have come to mind:

Removing the usage of these build time constants (something you mentioned @Korilakkuma )

    // TODO: Remove these envs
    __USE_SUBTITLES__: false,
    __USE_ALT_AUDIO__: false,
    __USE_EME_DRM__: false

...and refactor how we check for existence and instantiate controllers to something where we can handle controllers generically.

Perhaps the static Hls constructor can hold a "registry" of sorts where a "component" (simply a wrapper around a controller) can register itself. To start, by default the registry could hold today's core components. Later on that may change where we split out more functionality out of the core bundle.
Flow example:

• page loads hls.core.js
  • Hls.registry is now available on the global scope
  • auto-registers core components
• page loads `hls.subtitle-track.js' (a component)
  • the component registers itself (e.g. Hls.registry.add( ... ))
• page load complete
• page invokes new Hls(config)
  • internally, hls.js will retrieve all registered components
  • e.g. storing instantiated components as a Map<ComponentKey, ComponentController>

For public APIs such as get currentLevel - that could look something like:

// Note: Code is verbose to show intentions
public get currentLevel () {
  const controllers: Map<ComponentKey, ComponentController> = this._controllers
  const streamController: StreamController = controllers.get(ComponentKey.Stream)
  return streamController.currentLevel
}

Following that, we could refactor how we currently handle optional controllers (aka, controllers that now exist in the "extra" bundle)

// Note: Code is verbose to show intentions
  get subtitleTracks () {
    const controllers: Map<ComponentKey, ComponentController> = this._controllers
    const subtitleTrackController = controllers.get(ComponentKey.SubtitleTrack);
    if (subtitleTrackController) {
       return subtitleTrackController.subtitleTracks
    } else {
       console.warn('Missing subtitle track component')
       return [];
    }
  }

Thoughts @Korilakkuma ?

[michaelcunningham19]

While this does work to split out certain code to a separate file, I'm not a huge fan on the regular expression use here. Generally speaking this doesn't solve the modularity problem that #2175 is aiming to solve

Perhaps the naming of the chunk should change to better reflect the intention: light -> hls.extra . And on the same thought, perhaps renaming main -> hls.core or similar. Thoughts?

[johnBartos]

I haven't given this an in-depth look, but I believe that captions should be included in the core bundle. It's a heavily used feature.

[Korilakkuma]

The 2nd PR (WIP) implements the following items.

• page loads hls.core.js
  • Hls.registry is now available on the global scope
  • auto-registers core components
• page loads hls.subtitle-track.js (a component)
  • the component registers itself (e.g. Hls.registry.add( ... ))
• page load complete
• page invokes new Hls(config)
  • internally, hls.js will retrieve all registered components

So, Add (static method) is implemented to Hls.
And, optional component is registered by this method.

I would like to have a review not details of changed code but directionality 🙏

[michaelcunningham19]

@Korilakkuma - I did not forget about this 😄 I plan on reviewing soon :) I have been very busy lately which has caused me to be more or less absent on this project

[robwalch]

These changes aren't something I'm looking to bring into the current roadmap. See #2910 for details on new module exports.

[robwalch]

Following up on my last comment. I have been thinking about how we could achieve this with ESM modules and something like a composable player constructor (#2175 remains open). The difference between this attempt, is that I wouldn't want us to have to change the controllers or any of the core/network components. I would also want to avoid breaking up the library into multiple scripts.