Don't load hls.js from Cloudflare

[mxmtsk]

Is it possible to not load hls.js from cloudflare but locally from the own server? We are building a client website that cannot load from third party sites.

[mryarbles]

I had the same issue. Had to fork this project to resolve.

[mxmtsk]

I have done the same. I wonder if a PR would be accepted @cookpete cause that would solve a lot of GDPR issues in Europe if you could just reference a local file or your own CDN. :)

[schuylr]

Ideally this should be bundled as a dependency, or at least give us the power to define where it loads from.

[tim-mit]

FYI you can achieve this already and don't need to fork the project or wait for any changes before doing so.

The code that by default loads hls.js (and dash) from a CDN first calls the function at https://github.com/CookPete/react-player/blob/master/src/utils.js#L63-L66. What this does is check for the following window variables existing;

• window.Hls
• window.dashjs

These values are defined in HLS_GLOBAL and DASH_GLOBAL in https://github.com/CookPete/react-player/blob/master/src/players/FilePlayer.js#L11,L14.

If the variables already exist then instead of sourcing the libraries from the CDN react-player simply expects the libraries to already be available at those variables. So all you need to do in your own code is source the libraries as you see fit, attach them to those window variables and then use react-player.

We use this in our own codebase and it works fine. It could be worth including this info in the documentation somewhere?

[dancron]

I am preparing to deploy this code to run on servers across the world in production. Some installations will have the server and the client (laptop/browser) connected to the internet, and some installations will be on local networks which are not connected to the internet. Thanks to the window variables provided (see the comment by @tim-mit), it won't be too hard for me to get this to run without internet connectivity.

However, my vote would be to change the code so that by default it does not dynamically download hls.min.js at run time. I would prefer the default to change so HLS is included at build time.

[cookpete]

However, my vote would be to change the code so that by default it does not dynamically download hls.min.js at run time. I would prefer the default to change so HLS is included at build time.

This would bundle a 242 KB file into the library, for every implementation, regardless of if they are using HLS or not. Hopefully it's obvious why this isn't a great idea.

@tim-mit's solution is a happy coincidence, but actually quite elegant. Simply including the script (eg <script src="https://cdnjs.cloudflare.com/ajax/libs/hls.js/0.12.4/hls.min.js"></script>) before mounting the player, the library will use whatever is loaded in the global scope, as long as it makes the correct global available.

[ahmad-crossplatform]

Hello guys , I am pretty new to React and web development in general .
@tim-mit mentioned that we can change the values of HLS_GLOBAL and DASH_GLOBAL to get what we need by accessing some kind of window .

What does that mean ? does the window mean the div that wraps React-Player component ? or is there another way to access HLS_GLOBAL and DASH_GLOBAL ?

Edited:
now i have the code like this before I place the React-Player component

	window.Hls = "https://cdnjs.cloudflare.com/ajax/libs/hls.js/0.12.4/hls.js";
	window.dashjs =
		"https://cdnjs.cloudflare.com/ajax/libs/dashjs/3.0.0/dash.all.debug.js";

and that managed to crash the code which means i am getting closer , but what values i should place here ?
I got the following error
Uncaught (in promise) TypeError: Hls is not a constructor

[tim-mit]

You'll need to get the Hls constructor that Hls.js exposes attached to the variable window.Hls.
The variable window is a special global object that the browser always has available, if you don't scope your variables differently they will be available as window.<variable name>.

From the looks of things just including <script src="https://cdnjs.cloudflare.com/ajax/libs/hls.js/0.12.4/hls.js"></script> before your own code will likely be enough no more code required as once that external code loads it sets window.Hls. Be careful of asynchronous loading though, i.e. don't try and auto-play in your own js code that may end up being invoked before the third party library has loaded.

If you're using npm modules you may be able to find one of those that packages hls.js up and then not have to worry about the script tag or async loading. You'd just import the Hls constructor provided by the module and then set window.hls to the value you imported.

[subvertallchris]

If anyone is using webpack and struggling with getting it just right, you can do it in your webpack config using imports-loader like this:

    rules: [
      {
        test: require.resolve('react-player/lib/utils'),
        use: 'imports-loader?window.Hls=hls.js'
      },
    ]

I think this is a pretty unfortunate workaround, it feels brittle and unnecessary. While I agree that bundling Hls.js with ReactPlayer unfairly penalizes folks who aren't using hls, I feel like there should be a compromise to avoid quietly downloading files from a CDN. This might be extreme but maybe the Hls portions of this library could be split out into a separate package that includes hls.js as a dependency, similar to what you see with Apollo, Babel, Uppy, etc,...?

Regardless, thank you for your work on this library, it's excellent.