Discuss: Time to go ESM only? (for NPM `highlight.js` package)

This is on the v12 possibilities list: #3219. Some were pushing us to do that last year but it felt very premature at the time. Come this May it will be one year later… and I’m thinking of perhaps a summer release for v12.

Related: #2600

To be clear: this is only discussing highlight.js NPM package, not the highlightjs/cdn-release which will continue (for now) to include our default web build (CJS monolith, CJS modules, ES modules).

If we decided to do this I wonder what the “so you’re stuck on CJS” story would look like other than “tough luck”?

• Keep using v11 (for 6 months) and then “tough luck” is one potential story…
• It would be fairly easy to add a web build that adds global.hljs = hljs // etc to the end of the build, allowing v12 users to (as a hack) use the v12 web/CDN build and modules if they must stay on CJS.

Opening up for discussion.. CC @highlightjs/core

---

Proposed changes if we go ESM only:

For the node build:

• We no longer build the lib CJS folder
• We rename the es folder to lib
• the -ne (don’t build ESM) build flag goes away
• simplify package.json to remove all ESM + CJS stuff
• the es files become the actual built source, rather than merely stubs as they are now

[joshgoebel]

I seem to hear absolutely zero people saying “we still really need CJS”… 💯

[joshgoebel]

It’s a “façade” on purpose. I did quite a bit of reading at the time and from what I could determine this is/was the recommended way to publish a dual NPM package for Node.JS. If you make the ESM module truly stand alone then it becomes possible for someone to accidentally import the CJS library AND the ESM library (via different peer-dependencies). Then you have two different instances of the library when you only expect one.

The “facade” solves that problem. When CJS support is dropped the facade goes with it.

If I recall correctly our web ESM build is fully standalone as it does not have to deal with this Node.js ecosystem drama.