chore: migrate NetworkDetails from any -> null|XMLHttpRequest|Response;

[ondreian]

This PR will...

Properly declare the type for NetworkDetails

Why is this Pull Request needed?

Removes reliance on any type in favor of properly declaring NetworkDetails for better developer ergonomics when matching against HTTP outcomes

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

I traced the usage of NetworkDetails as best as possible to all existing usages in the codebase and found that in some cases it is declared as networkDetails? type and sometimes is is passed as a null object. I did not clean this up because technically it could be a breaking change, but converging it so that networkDetails? is preferred would make sense for code clarity and overall maintainability in the future.

Resolves issues:

resolves unnecessary dependence on any type

Checklist

• 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

[robwalch]

Thanks for these changes. This should be helpful for anyone using the default loaders, and for improving internal type safety.

In a situation where someone provides their own loader via config.loader (or pLoader or fLoader) and they want to provide their own struct to networkDetails I wonder how using the project type exports will impact them.

[ondreian]

That is a good point, perhaps I need to expand the callback interface to be expressed with some generics and have the default argument be NetworkDetails here.

Another option is to keep the current definition and say that a pLoader or fLoader must return one of these 3 types, in case we ever need to manipulate it internally we can have a verified interface versus a generic (that we can never verify like that), and they can cast Response | XMLHttpRequest to their custom struct in their provided callback and outside of the hls.js internals

[robwalch]

Use type imports where possible.

As for the build failing, my best guess is something about these changes would result in a type-check error in TS 4.1 (can't imagine what) and since that is what api-extractor (for which there is no update) is using, it errors silently). We could try making the api-extractor run verbose temprorrily. I don't know if we can force a new TS peer dependency to be used. Let's see if type imports mak a difference first (we should be using them anyway).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[robwalch]

Would prefer to see NetworkDetails | null where nullable.