Proposal: ESM-Only Distribution – Deprecate CJS for Simplicity

[jimmywarting]

While attempting to import the ESM build from a CDN, e.g. https://cdn.jsdelivr.net/npm/highlight.js@11.11.1/es/core.js in the browser, the module fails as it internally references ../lib/core.js (a CJS module).

Dual-package (CJS + ESM) support has become hazardous, causing errors in modern ESM environments and making the ecosystem experience confusing and fragile.

---

Proposal

• Transition highlight.js to ESM-only distribution (or ESM-first with minimal CJS fallback, if truly necessary).
• Ensure all distributed files referenced in the published ESM build are themselves ESM, and all internal imports are relative and ESM-compliant.
• Improve and clarify CDN/browser module usage in documentation.

---

Additional Rationale: Node.js Compatibility

Recent Node.js versions allow importing ESM modules from CJS code, making an ESM-only package feasible for both server and client contexts.

For older Node.js versions, import() can be used in CJS files to lazily load ESM modules. This provides a smooth upgrade path and backward compatibility for environments not yet fully migrated to ESM.

• Node.js Docs: ESM in Node.js
• Node.js Docs: Dynamic import() Expressions

Fully embracing ESM will not break Node.js consumers, since all modern and LTS Node releases support ESM, and CJS users have the built-in dynamic import workaround.

---

Benefits

• Easier CDN / browser integration for modern frontend frameworks and deployments.
• Simplifies maintenance and reduces ambiguous bugs related to dual packaging.
• Aligns with the JavaScript ecosystem, which is moving ESM-first (Node 18+, Deno, modern bundlers, etc).
• Reduces long-term complexity and increases reliability for all users.

---

Thanks for considering this proposal!

[joshgoebel]

Closed as a dup of #3219. This is already planned for v12, but I have no ETA for you on that ATM.