Discuss: CDN builds should include ESM ready modules

[joshgoebel]

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 #3188 (comment)

[joshgoebel]

My key concern OTTOMH is the how/instructional side. We have a very clear process for using CJS modules via script tags:

<script src=".../cdn-release@10.7.1/build/highlight.min.js"></script>
<script src=".../cdn-release@10.7.1/build/languages/go.min.js"></script>

Two lines, done. Languages auto-register. Meanwhile for ESM:

import hljs from 'highlight.js/lib/core';
import javascript from 'highlight.js/lib/languages/javascript';
hljs.registerLanguage('javascript', javascript);

A bit more elbow grease... is this just expected? Is there a shorter form of writing that like you can with require (without forcing us to make our API async)? If we support ESM do people suddenly expect some sort of magic async API to make working with ESM easier?

[joshgoebel]

IF there were no other library changes that needed to be made then I think we could build a CDN ESM version and just include it in an es folder inside build...

./
- highlight.min.js (CJS)
- languages (CJS)
- es
  - languages (ESM)
  - highlight.min.js (ESM) 

Although I suppose I'm open to alternative suggestions if there is a common standard - BUT I'm not sure that moving the CJS files from their historic places is desirable at this time... but I suppose that would leave open the argument for a bunch of mjs files side-by-side with CJS perhaps?

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

[jimmywarting]

I would like a very minimal cdn bundle...
I would also want an async version where non of the langauges is imported but where all the languages is supported/listed/mapped and only imported dynamically on demand.

import hljs from 'highlight.js/lib/core';

if (hljs.supports(language)) {
  // takes care of import()-ing the js parser for the respected cdn automatically 
  hljs.highlight(code, { language }).then(html => {
    xyz.innerHTML = html
  })
}

if (hljs.supports('js') || hljs.supports( 'javascript' )) {
  // takes care of import()-ing the js parser for the respected cdn automatically 
  hljs.highlight(code, { language: 'js' }).then(html => {
    xyz.innerHTML = html
  })
}

Right now i think that it only supports like 32 with the default bundle. but you do support more langauges than that... i want to support every language that you support (lazily).

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