I believe there came the time to move highlight.js away from its ad-hoc
module system usable only in a browser to something more formal. I was
reluctant to do this in the past because nobody was able to formulate
the problem that it will solve. And the argument "everyone does this" is
not exactlypersuasive :-).
However after some personal emails and GitHub comments I finally figured
it out. The problem is: highlight.js is not usable in node.js. You can
do this only by maintaining a separate fork which is suboptimal. Sorry
for taking so long to get it!
I've reviewed a couple of proposed solutions and made myself familiar
with the modern (sad) state of affairs on this and now I want to discuss
our options. I see two of them:
1. AMD and require.js all the way.
Each language and the library are wrapped into `define('name',
[..requirements..], function() {})`. These modules can be used in
node.js[1] and they can be build into a single .js file usable in a
browser using the build tool provided by require.js. I don't see any
problems here but this is probably for the lack of experience. I think
we won't even lose the additional custom minimizations to variable names
that the current build.py does because they can be applied before the
final build process.
I also don't want to lose the current implicit in-browser API: the
library is in the global variable `hljs` and you can dynamically add
additional languages with `hljs.LANGUAGES.name = ...`. Can anyone
explain if it's possible?
Another thing that I'm not sure how to do is using the requirements
inside a module definitions. We now have django.js that defines Django
highlighting by borrowing everything from hljs.LANGUAGES.xml that is
already defined by the time. How does this translate into the require.js
world? Will "xml" module be passed into the "django" module function?
2. Two build targets.
Each language file will contain exactly one anonymous function returning
a language object. The build tool will have two different targets, say,
"browser" and "amd" that will wrap the file content into the appropriate
boiler-plate:
- "browser":
'hljs.LANGUAGES.name = ' + <file> + '(hljs);'
- "amd":
'define("name", ' + <file> + ');'
The module format in this case may not be the AMD endorsed by require.js
but also a common.js, "native" to node.js (why *everything* has to end
with ".js"???). We even can have two different module build targets.
---
I don't have any objections to either of those ways but I'm probably +0
in favor of the first way. What do others think?