Possible plan for node compatibility etc

[curiousdannii]

Many years ago I sent a PR for node support (#18). I think I've come up with a better plan now.

So the main problem with how the various components are organised at present is that the references to the other components are hardcoded using globals. I think it's much better if each component is a factory function rather than a singleton, so that the framework that uses GlkOte can construct the components in the order it wants, and pass in the references to the other components dynamically.

So like my old PR, I'd like to keep that aspect of it. The differences from the old PR would be:

• use ES modules rather than CommonJS modules
• provide a file that would load the components and set them up
• use Rollup to bundle that file and the component files to produce an output file that would be a drop-in replacement for the current concatenated glkote.js used by Quixe

It should be possible to do this with literally no other changes required for classic Quixe usage, but to then give Parchment/Lectrote/etc the flexible to use the components as they need.

[erkyrath]

I went through a process of node compatibility last year. Now every file ends with a line like

try { exports.GlkOte = GlkOte; } catch (ex) {};

This is clunky but it allows Lectrote to load everything in with "require" statements. But then it has to assign all the modules as window globals, because that's how they refer to each other internally.

I agree that ES modules are the way to go. I need to comb through the entire set of projects and shift them over to modules and "require". This is not going to happen this release, though. (I am aiming at a glkote/quixe/lectrote release today or tomorrow.)

Keeping this open for the next major release.