(build) browser build is CommonJS and IIFE (global)

[joshgoebel]

• dropping support for AMD, which we never truly supported
  in the first place

  Resolves Require using AMD broken in 10.0.0 #2505. Also think this will close highlightjs.org build seems to differ from ./tools/build.js -t browser :common #2291

[joshgoebel]

Essentially this is just IIFE (global) with a small footer to support CommonJS (since I didn't see the harm):

var hljs = (function () {
  'use strict';

  ...

}());
if (typeof exports === 'object' && typeof module !== 'undefined') { module.exports = hljs; }

Attaching a file for testing (it only includes plaintext and java):

highlight.js.zip

[egor-rogov]

Looks fine.

[avih]

I find it a bit hard to understand from the description, does this merge mean that the concatenated web-download can now work in node.js? does it have an effect on #1245

Thanks in advance.

[joshgoebel]

does this merge mean that the concatenated web-download can now work in node.js?

@avih YES, AFAIK it should now work when used like that. I'm still not sure that's optimal, but it was an easy thing to enable in hindsight - once we gave up AMD. There is a chance in the future we might compile the web build differently (if browser techs moves slower than Node.js) which would make it larger/slower than the NPM Node.js build... but for now...

FYI: The browser build the build system itself generates definitely can be required by Node.js, that's part of our CI testing now.

If you test a download from the website and it works, please let me know and I'll bump that thread with an update.

[avih]

Thanks a lot! I'll bump this thread once I have tested it (not right away, but I intend to)

[avih]

@avih YES, AFAIK it should now work when used like that.

Indeed it seems to be working :)

I went to https://highlightjs.org/download/ , created some custom package (the default languages and few more), and it seems to be loading fine and working in node.js as is.

Thank you! (even it it won't last forever, but then again, what does last forever? ;) )

As a side note, any chance you can add a button at the download page to select all/default checkboxes?

[joshgoebel]

As a side note, any chance you can add a button at the download page to select all/default checkboxes?

That'd be a task for @isagalaev ... but the page should default to the defaults by default and remember custom choices in a cookie.

[avih]

the page should default to the defaults by default and remember custom choices in a cookie.

Correct, but if someone wants to download everything then it's quite tedious.

[joshgoebel]

Literally everything isn’t even advised. It will be huge and slow to autodetect anything.

[avih]

You could make exactly the same argument that anything beyond what you need exactly would be a waste of cpu cycles and storage space or network bandwidth, and yet your default includes 38 languages.

[joshgoebel]

I would say that’s entirely correct, yet we need some defaults so as to be immediately useful to people as something you can easily load via CDN and just quickly get started easily.

I think we’re still pretty conservative with qhat we include by default with regard to how large some JS libraries are there days. Of course if someone knows they are NEVER going to need to highlight a given language it’d be better to not use the library with that language compiled in. That’s just common sense.

Anyways, as I said any changes to the website are fully up to @isagalaev and his time.

It’s already super easy with the main build tool to build a tiny or HUGE package, whatever one desires.

[avih]

You provide a useful thing, but you limit your users to what you think would be reasonable usage. Let users go wild, maybe someone uses it locally or server-side with enough space and cpu cycles to spare? maybe they don't do autodetection? etc.

(limit - in the sense that it's hard to select everything, even if not impossible)

[joshgoebel]

No limits. People can do whatever they want. :-). The defaults work well for “most people”.

FYI: Server-side you can easily require ALL the languages with a single require (via the NPM package), this has always been possible as far back as my involvement with the project at least.