Modularity of CDN built components

[joshgoebel]

If we start doing more stuff with ES6 modules there will be all sorts of opportunities to sharpen and share code between different grammars. Having “full support” for jsdoc and sharing that support across Java, Javascript, Typescript, etc would be possible just be importing a “jsdoc” module (possible a sub language, possibly just a helper). I know modern built tools (like Rollup) can handle this nicely... pulling in the jsdoc requirement a single time, even if 3-4 languages depend on it...

And when building a “monolith” the build system could do build-time checks (or just let the module system do it all) to make sure that your actual build includes “all ze pieces” for your requested functionality. IE, if you say “javascript” you get the jsdoc support automatically, etc.

But this leaves a big question for how we build independent modules... such as if someone built a “tiny” build (no languages) then wanted to load all the languages from CDN... Now are we back to resolving things at run-time? [Like we do now... IE, Arduino fails without CPP first loaded...]

If you try to load “javascript” do we show you an error and tell you “you must load jsdoc first”? I suppose we could just “lose” that functionality like we do now with sub languages, but that’s always seemed suboptimal to me.

Another choice would be to make each module “stand-alone”.... so you might have java.js, javascript.js, and typescript.js modules but they ALL would include a SEPARATE copy of jsdoc embedded so they could be used entirely stand-alone.

I think right now I like this latter approach a bit better. It trades size for “just works”... and really people wanting the tiniest build I think should build a monolith to take advantage of “tree shaking” of modules that we can share between grammars. I think there might be lots of opportunities for this in the future (CSS, SCSS, JSdoc, C/C++/Arduino/ Handlebars/HTMLBars, etc)...

Anyone else have thoughts?

[joshgoebel]

This could have big (and beneficial) maintenance implications for things that are shared... the fewer things we have to focus on the nicer each of those things can be (focused attention, vs spread). Right now (for example) CSS is much nicer than SCSS... because they are treated as discrete things rather than looking at what they share in common and trying to build on that foundation instead.

Also worth thinking about how this works with 3rd party (outside core repo) grammars... but as I dig into the build process I might have more thoughts on that. It would be nice if say the external “TS-SQL” grammar could build on top of the lower-level SQL grammar (if it was beneficial to do so) and other such situations that you might imagine coming up. Rather than bundling two SQL grammars that repeat so much.

[wooorm]

Prism doesn’t have a build system either but for refractor, in the case of arduio which uses cpp, I build something like this for refractor:

'use strict'
var refractorCpp = require('refractor/lang/cpp.js')
module.exports = arduino
arduino.displayName = 'arduino'
arduino.aliases = []
function arduino(Prism) {
  Prism.register(refractorCpp)
  Prism.languages.arduino = Prism.languages.extend('cpp', {
    // ...
  })
}

(I suggest against using register/extend though, instead making a pure new syntax)

---

For utilities, like jsdoc, you could put them in separate packages / files, and requiring those utilities from the places that use them?

[joshgoebel]

I'm not sure I follow... I understand how we'd go about doing it with require or import (and then compiling that or not)... I think I was asking about the larger packaging issues... we ship SEPARATE language modules for every language on the CDN builds... so you can optionally load extra languages one at a time and use a default "common" build of the JS module.

So if we switch to something nice like this we either have to build a system that does all this at run-time (like we do now for Arduino/CPP)... and then if you don't include the right files, it all breaks... or do it at compile tile... so the compiled arduino.js would simply include "everything" (a lot of that again duplicated in cpp.js). The advantage being your an easily include any language and it "just works".

I'm leaning a little towards each file being self-contained. If you need the smallest build you should build a monolithic JS with the language included (so we could take advantage of the requirements all being shared). That's my current thinking at least.

[joshgoebel]

Closing and right now I think in the future (overall) we will lean more towards compile-time requirements than run-time (which have resulted in more than a few issues filed). This seems to provide more stability and predictability regarding behavior.