Make the parser/compiler usable under Node.js (in a nice way). about qmlweb

[labsin]

Should we add a UMD? Something like github.com/umdjs/umd/blob/master/templates/returnExports.js

[henrikrudstrom]

@ChALkeR Yeah, i was getting annoyed at all the globals floating around.
Think it would be good to make a separate module for the parser/loading stuff, 'qmlweb-parse' for example, then this module can be required by the gulp task or future server side needs.

@labsin UMD looks good. Are there any implications except the extra code to wrap around?

[ChALkeR]

@henrikrudstrom Actually, I think we can just use CJS and Browserify/Webpack. I will take a look at this soon.

[Plaristote]

Checkout the browserified branch to see a few tweaks I've done to make qmlweb usable directly from nodejs.
The encapsulate helpers are gone, there aren't any global variables left (apart from the AutoLoader, which might need to move somewhere else, since it's useless for the nodejs environment).

I've made some exports, but mainly I've cut the access from the external world to most of what was stored in global variables. We should discuss on what gets exported and what doesn't.

We might also consider removing some of the gulp concatenation in favor of uses of require. That would be a much harder piece of work though, and not being an expert in node's require function, I'm not completely sure this is the best approach.
Anyhow, it would definitely help in making qmlweb more modular.

I can make a PR if you figure what I did in browserified was the way to go.
I'm not sure about the last step. I had to generate two lib/qt.js: one for nodejs, and one that takes the nodejs version and uses browserify on it.

[ChALkeR]

The proper way to fix this is described in #173, I think.
I nearly completed the split, see #215, #216, qmlweb/qmlweb-parser#6.

All those three points are done in qmlweb/qmlweb-parser#6.

[ChALkeR]

Implemented in qmlweb-parser.