Avoid re-exporting enums with "export type"

[ericmatthys]

This PR will...

Re-export enums with a standard "export" instead of "export type".

Why is this Pull Request needed?

When using "export type" with enums, the enums are not bundled in and cannot be use as values, even though they'll be included in type declaration files. This leads to runtime errors that satisfy the type checker. Reserve "export type" only for types and interfaces that cannot be used at runtime.

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

HdcpLevels is not an enum, but it is an array that can be used as a value at runtime.

Resolves issues:

Closes #5630

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

[ericmatthys]

I ran prettier to fix the lint error

[robwalch]

It looks like this would introduce a breaking change requiring named imports:

[!] Error: Entry module "src/hls.ts" is using named and default exports together. Consumers of your bundle will have to use `Hls.default` to access the default export, which may not be what you want. Use `output.exports: "named"` to disable this warning

This is likely why we add static getting to Hls for portions of the API we expect developers to use as runtime values (ex: Hls { get Events() } ).

[ericmatthys]

Oof, yeah. Some potential options...

• Don't use enums for the exported types to avoid the runtime error without a type error problem
• Switch to all named exports (breaking change)
• Switch to ESM only distribution (not sure if that's realistic)

[robwalch]

Don't use enums for the exported types to avoid the runtime error without a type error problem

Maybe the only viable option. I don't know if enums are providing any advantage size-wise in the ESM or minified ES5 output. I think we can get away with a compatible type change. Most important thing would be for them to remain consts.

[ericmatthys]

I'll open up a separate PR if I can get something working with that approach.

[ericmatthys]

#5729

[robwalch]

After reviewing #5729 I prefer looking into taking this PR, and providing an ESM build with named exports (minimal breaking change), and then somehow maintaining the default only export for the UMD build (no breaking change for UMD users)

#5729 (review)