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]

We could also export NetworkDetailsNullable or NetworkDetailsOrNull as a type to keep all the networkDetails: typing to a single type. I'd just like to keep the NetworkDetails type limited to object types that loaders will provided when they can.

I know this one has been sitting here for years. Let me know if you can pick this up or would like me to resolve it by closing or rebasing and merging after addressing these comments.

[ondreian]

I think this is what we would need to do, since it it not exactly obvious exactly where null can be converted to the other types here due to the lifecycle of events and it would be safer to err on the side of defensively coding around this but representing that an end implementor needs to handle null gracefully.

[ondreian]

I have not touched the internals of the hls.js codebase in a long time, but let me see if I can't pick this up and fix it tomorrow.

[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).

[robwalch]

Would prefer to see NetworkDetails | null where nullable.

[ondreian]

superceded in #7458