Add minified ESM builds and a dist size budget check

[itsjamie]

This PR will...

Add minified ESM builds, dist/hls.min.mjs and dist/hls.light.min.mjs, from two new rollup configs. Both are added to the es-check ESM group so they hold to the same esmodules: true syntax floor as the unminified .mjs files.

Also adds npm run size and npm run size:check, and runs the check in CI. Budgets live in dist-size-budget.json and are compared against brotli, since that's what CDNs serve.

file	raw	gzip	brotli	limit	headroom
hls.js	1643.6 KiB	359.7 KiB	277.1 KiB	282.7 KiB	5.5 KiB
hls.min.js	602.7 KiB	183.6 KiB	149.8 KiB	152.8 KiB	3.0 KiB
hls.mjs	1445.1 KiB	335.4 KiB	261.2 KiB	266.4 KiB	5.2 KiB
hls.min.mjs	577.3 KiB	176.6 KiB	144.0 KiB	146.9 KiB	2.9 KiB
hls.light.js	1043.8 KiB	232.4 KiB	183.0 KiB	186.7 KiB	3.7 KiB
hls.light.min.js	375.2 KiB	116.3 KiB	97.6 KiB	99.5 KiB	2.0 KiB
hls.light.mjs	923.9 KiB	218.2 KiB	173.5 KiB	176.9 KiB	3.5 KiB
hls.light.min.mjs	361.6 KiB	112.8 KiB	94.9 KiB	96.8 KiB	1.9 KiB
hls.worker.js	115.4 KiB	40.0 KiB	35.1 KiB	35.8 KiB	0.7 KiB

Every budget is recorded at the current size, so the headroom is entirely the 2% tolerance.

Nothing changes in main, module, or exports. The existing "./dist/*" subpath already resolves the new files.

While in the README I fixed two things that were wrong: the flag is --configType, not --env, and the demo config isn't always built, it's only built when no --configType is passed. Also documented that the ESM builds don't inline the transmuxer Web Worker, with the workerPath snippet for that.

Why is this Pull Request needed?

#2910 asked for ESM so modern browsers could load us from a CDN with <script type="module">, and the naming proposal in it included minified variants. #5299 shipped one unminified target, #5484 got hls.light.mjs, and the minified ones never followed.

So people are pulling them from jsDelivr anyway. In the last month /dist/hls.min.mjs on 1.6.16 took 180,597 requests for a file we don't publish, which jsDelivr generates by auto-minifying hls.mjs (1,306,989 → 564,361 bytes served). /+esm took another 3,840,230. That output isn't produced by our build and isn't checked by es-check.

Meanwhile ~99% of file hits on 1.6.16 go to /dist/hls.min.js. Out of 7B requests last month, effectively everyone is taking the UMD bundle and a global Hls. A real minified module is what an import map entry can point at, and it's the prerequisite for anything I'd like to do later with module-level loading.

On the budget side, #3830 and #4936 both asked for size to be treated as ongoing work rather than answered once.

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

The tolerance is 2% and it's a judgement call, I'd rather it be the project's than mine.

Resolves issues:

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

[itsjamie]

The intention isn't for this to be a blocker for merging, because as @robwalch mentions in #4936 features will add bundle size to the library. But more to simply be aware of it, and start to track it. At this point, the total amount of traffic this library receives and size is enough (to me) to start to want to be aware. I set the tolerance at 2% because at the current bundle sizes that is a significant total size different of >5Kb of text (after compression). Which should be quite a large feature if the dist check in CI causes any issue, and it's very easy to change by updating the JSON file it compares against.

However, like mentioned above that's my intention, and I'd rather this be a project decision. I'm revisiting this because over the last year, jsdelivr served hls.js for 10PB of traffic. That's pretty nuts to me 🙂