Discuss: CDN builds should include ESM ready modules

We already have a ton of infrastructure, history, documentation around making our web builds available via CDN (and secondarily) via NPM via con-assets… if we do have an ESM library that is intended for use on the web then it should be built with cdn and packaged along with the CJS version in our CDN distribution. It would be very strange for it to not be included there. That may require some additional work/thought… so if you want to have that discussion…

_Originally posted by @joshgoebel in https://github.com/highlightjs/highlight.js/pull/3188#issuecomment-844207270_

[joshgoebel]

@aduh95 If you’re interesting I think this is quite likely as simple and taking the ESM build code I removed from node build before and migrating it over to the cdn build…

[joshgoebel]

I would like a very minimal cdn bundle…

This bundle already exists (CDN build): es/core.js

I would also want an async version

This currently does not exist. This would require several complexities be resolved before it could exist in core:

• whole new async API for highlight* and perhaps registerLanguage / getLanguage
• nested grammar dependencies also need to “just work” (http -> html -> (css/js)), including circular dependencies (html => js => html)
• need a way to extract & register aliases at compile time rather than runtime (aliases are currently unknown until AFTER grammars are loaded)
• need a way to specify which grammars a person does NOT ever want to load

I’m probably forgetting things, you’d have to skim several of these threads - I’ve definitely written on this subject before.

Also, see #2405. Right now I’m unconvinced that this isn’t better handled by a wrapper outside of core such as say a new highlightjs-async library that simply wrapped the core library with async niceness. (you’d have to handle aliases and the dependency graph, plus a nice async wrapper)