[Request] Provide a core version for CDN to be used in browser

[yihui]

Currently highlight.min.js is about 120Kb, which is not bad, but I often only need the support for only a few (most likely to be no more than three) languages on a page. I wonder if you'd consider providing a bare minimal core version on CDN, and users can selectively load the languages they need. This is possible for ES6 modules:

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

and it will be nice to be able to do this in browser, too:

<!-- load the core -->
<script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release/build/core.min.js"></script>

<!-- then load languages we need -->
<script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release/build/languages/c.min.js"></script>
<script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release/build/languages/go.min.js"></script>
<script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release/build/languages/latex.min.js"></script>

Thanks!

[joshgoebel]

Pretty sure we already do this:

• https://github.com/highlightjs/cdn-release/blob/11-stable/build/es/core.js
• https://github.com/highlightjs/cdn-release/blob/11-stable/build/es

[yihui]

Yes, I was aware of the core module, but I meant a script that could be loaded in browser via <script src=""> instead of

<script type="module">
import hljs from "https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.7.0/build/es/core.min.js";
</script>

The module won't work:

<script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.7.0/build/es/core.min.js">
</script>

I know that highlight.min.js was built via node tools/build.js :common, and my request was to build a core version without :common languages and release it to CDN.

[joshgoebel]

And of course you can build your own version easily enough with how every many (or few) languages you want... I think the version we currently ship is a great mix for many at a very low cost - only 40kb gzipped.

I'm lost though. We currently ship core in both ESM (ES modules) and CJS (ILM) versions, I'm not sure exactly what you're asking for here.

[yihui]

Sorry about the confusion. Yes, I know I can build my own version, and I was hoping for an "official" release.

Let me try to clarify what I was asking for. First, this is what we typically do:

<script src="build/highlight.min.js"></script>

<!-- then load extra languages we need, e.g., latex, which is not in :common -->
<script src="build/languages/latex.min.js"></script>

highlight.min.js contains 30+ common languages, most of which I rarely need. What I wish for is a core.min.js that contains no languages at all, so that I can load any specific languages I need:

<script src="build/core.min.js"></script>

<!-- then load specific languages we need -->
<script src="build/languages/c.min.js"></script>
<script src="build/languages/latex.min.js"></script>

I don't have much expertise on JavaScript, so please forgive my ignorance. If this core version is provided, I can use jsdelivr's combine feature to combine the core with the few extra language files, and the result would be super lightweight (although I agree the current highlight.min.js is relatively lightweight, as I mentioned in my first post).

Again, I don't know much about tools for building JavaScript, and my gut feeling is that this task could be done by adding a line after:

highlight.js/tools/build_cdn.js

Line 56 in 14aa378

const size = await buildCore("highlight", embedLanguages, { minify: options.minify, format: "cjs" });

something like this?

  await buildCore("core", [], { minify: options.minify, format: "cjs" });

If that sounds about right, I can submit a pull request. Thanks!

[joshgoebel]

Yeah, this older usage (CJS/ILM) is what we're moving away from - in favor of ES6 everywhere. Simply use the new ES6 code (with modules) and you already have everything you need with existing builds.

At the moment we have no plans to expand the scope of the CJS library. I may go away entirely with version 12 and those wanting to stay on CJS a bit longer would keep using version 11.

[yihui]

Thanks for sharing the possible roadmap! I don't know your motivation to drop the support for CJS, but the old usage is critical to me. This made me take a look at Prism for the first time, although I've heard about it for a long time. I was happy to find out that it has exactly what I asked for in this issue:

<script src="https://cdn.jsdelivr.net/npm/prismjs@1.29.0/components/prism-core.min.js"></script>

And the core is tiny. I'll take a closer look in the next few days.

I have been a happy highlight.js user for over a decade, and I truly appreciate the contribution from all authors/maintainers/contributors!

[joshgoebel]

but the old usage is critical to me

Why?

This made me take a look at Prism for the first time

Prism is great, but they are also going ES6 (and dropping support for older browsers) with the next release IIRC - though I'm not sure about their plans to continue to publish older CJS builds...

[joshgoebel]

I don't know your motivation to drop the support for CJS

Same old reasons: ongoing development and support costs are higher with multiple versions of things.

• We haven't supported IE and other old browsers for some time.
• We officially support only green-field browsers and Node
  • all these environments well-support ES6 modules in 2023...

[joshgoebel]

Just played around with this briefly, using rollup one can generate CJS versions of ES modules super trivially:

rollup -f iife -i build/es/core.js -o core.cjs.js --name hljs

[yihui]

Why?

Maybe it's my ignorance, but to my knowledge, modules must be defined in external files. My use case is to make an html file self-contained (which can be easily shared and viewed offline) and not rely on external files, which means all JS code must be embedded in the html file. With the good old CJS, this is quite trivial to achieve---simply read the external JS code into the <script> tag. With ES6 modules, this doesn't seem straightforward to me, i.e., how to convert import foo from "bar.js" into self-contained JS code that can be embedded directly in <script>? Maybe there are special tools and I don't know.

Just played around with this briefly, using rollup one can generate CJS versions of ES modules super trivially:

Thanks! I was aware of tools like rollup and have used it a couple of times before. Indeed it is trivially easy. Exactly because of that, I was asking for the "official" support. I understand that maintaining multiple versions of things brings complexities, but in this case, I don't see a high support cost (the only risk I could see is that rollup might die someday and you'll be in trouble, but I feel that's quite unlikely).

Prism is great, but they are also going ES6 (and dropping support for older browsers) with the next release IIRC - though I'm not sure about their plans to continue to publish older CJS builds...

I'm always in favor of dropping support for older browsers. I don't care about older browsers. If they are going to drop CJS builds, too, I guess the only way I could move forward is to build them by myself. I hope not to do that, but a last resort is better than none.

[joshgoebel]

use case is to make an html file self-contained

This is an edge case already (yet readily solved with a tool such as rollup).

I don't see a high support cost

This is either a tip of the iceberg problem or else a "how high is too high"... We currently maintain (and test) 3 different builds of the project, we force 3rd party authors to worry about multiple build types. We must maintain documentation for require and import, etc... it's been quite painful trying to figure out the "best" way to ship a combined CJS + ES6 library... there are all sorts of small headaches that add up. This is all effort and complexity that we would rather not deal with - IF it can be avoided.

Many libraries went ES6 only a year or so ago - we purposely held out then... but now it's time to take the leap. Those wanting CJS can easily use Highlight.js 11 a while longer, or just run us thru a build tool such a rollup to generate legacy output.

[yihui]

Many thanks for the explanation! That makes sense (and also resonates with me as an open-source developer).