Research if and how we should support 3rd party javascript libraries from QML.

JavaScript libraries may attempt to do things not allowed by the QML JS environment. For example:

Modify native objects:

• http://sugarjs.com/
• http://www.datejs.com/

Modify the global object:

• http://www.diveintojavascript.com/projects/javascript-sprintf
• http://documentcloud.github.com/underscore/

Many libraries seem to be looking for either a browser environment or a CommonJS-like environment:

• https://github.com/willconant/flow-js (CommonJS "exports" or "window" for browser)
• http://persistencejs.org/ (CommonJS "exports" or "window" for browser)
• https://github.com/caolan/async (CommonJS "exports" or "this" for browser)
• https://github.com/michael/data (CommonJS "exports" or "this" for browser)

In some cases, existing libraries can be made to work with code like:

var window = {}
Qt.include("persistence.js")

Possible solutions:

• Many libraries introspect their JS environment and tweak their code to cater for different environments. We could offer a standard way to identify the QML environment, allowing libraries to tweak themselves to our environment as well
• We could consider introducing a new pragma, or allowing ".pragma library" imports to do special things (e.g. have their own (private?) editable global object)
• A pragma that bootstraps some sort of compatibility layer (like Envjs)

Other notes:

• There seem to be a particularly large number of libraries tailored to node's JS environment: https://github.com/joyent/node/wiki/modules, though it isn't immediately clear how many would also be relevant to QML.