[Enhancement request] Allow importing named language imports

Is your request related to a specific problem you’re having? When using a bundler on the front-end it is important to only include the required languages to reduce bundle size, but it feels a bit clunky to register languages like this:

import hljs from 'highlight.js/lib/core';
import js from 'highlight.js/lib/languages/javascript';
import json from 'highlight.js/lib/languages/json';
import yml from 'highlight.js/lib/languages/yaml';
import md from 'highlight.js/lib/languages/markdown';

hljs.registerLanguage('javascript', js);
hljs.registerLanguage('json', json);
hljs.registerLanguage('yaml', yml);
hljs.registerLanguage('markdown', md);

The solution you’d prefer / feature you’d like to see added… It would be much better if it could just be done like this:

import hljs from 'highlight.js/lib/core';
import { javascript, json, yaml, markdown } from 'highlight.js/lib/languages';

hljs.registerLanguage('javascript', javascript);
hljs.registerLanguage('json', json);
hljs.registerLanguage('yaml', yaml);
hljs.registerLanguage('markdown', markdown);

This only requires adding lib/languages/index.js which has lines like:

export { default as json } from './json';
export { default as javascript } from './javascript';
// aliases could be done like this:
export { default as js } from './javascript';

I could make a PR for this (please mention whether aliasing is desirable, I believe this could also be implemented in client code as import { javascript as js } from 'highlight.js/languages')

[joshgoebel]

▲ = node ./build/es/test-es-imports-index
The script uses approximately 7.31 MB
▲ = node ./build/es/test-es-imports
The script uses approximately 3.83 MB
▲ = node ./build/lib/test-cjs-imports-index
The script uses approximately 7 MB
▲ = node ./build/lib/test-cjs-imports
The script uses approximately 3.52 MB

So correct, it adds about 3.5MB of RAM for all languages. I’d argue that’s negligible for Node

I think this line of thinking is why modern software can be so slow when computers are faster than they’d ever been… I just don’t see a large enough win here to justify these changes. We increase code complexity, compile times, increase RAM usage…

it would be dramatic (and unintended) if it were bundled in web bundlers though

…and potentially vastly increase the download size if someone’s bundler isn’t properly tree pruning or analyzing side effects properly… (a bundler or config problem)

Too many negatives for a tiny quality of life change that truly only effects someone just getting started with Highlight.js on a new project. Just adding a new language to an existing file takes almost no time and the list of imports isn’t something someone one needs to constantly fiddle with…

---

I did add this to the v12 list to re-review to see if anything has changed.

Closing this issue and the PR for now.

[joshgoebel]

In reviewing this again (just now) for consideration for v12 I still find it lacking in that it would potentially force a ~ megabyte of unneeded JS to be downloaded and parsed. IMHO this makes more sense if/when we go fully async so that registering the languages doesn’t actually perform any actual requests or parsing… so one could either say:

• register these languages, then allow them to later load on demand

OR

• register these languages, and pre-load them now

But in both cases only the specified languages would ever be download and parsed, not every single language that was in the index.