Node/Browser Compatibility

Not logged in

Node/Browser Compatibility notes

Creating a set of modules which can be used normally from both Node (via require) and the browser (via <script> tags) is non-trivial. Node would prefer to install all your modules in node_modules, so they can be loaded via a plain require('modulename'). Script tags require full paths, and the usual organization for web content is at odds with filing JS files away in some obscure directory. We have to break a few rules on both sides of the aisle in order to make things work.

Browser

Arend modules are loaded via <script> tags. Modules must be loaded in dependency order.

The core module establishes a global pseudo-require function that tries to return the "module" requested. Depending on the argument, this may be the global ar object (for Arend-internal modules) or some specific object (for utility modules like Lo-Dash, No-Dash, and Fin).

All Arend modules access other modules (Arend and utility) via require; direct access through global objects (even though these are available on the browser) is never used.

Node

In Node, modules are located both in src/ and lib/. Relative module paths are used in require() calls, to avoid the need for the Node module directory structure. All modules depend on core, thus it is guaranteed to be loaded first (which is good, because it installs Lo-Dash globally).

QUnit

Although QUnit can be used from Node, it doesn't do anything useful. It doesn't report any results, or, indeed, run any tests. Hence, when run via Node we require a small wrapper around QUnit, "QNodeit" which sets up QUnit for CLI operation. It simple loads QUnit, changes a few config settings, and then re-exports all of QUnit's exports. The web-based test suite loads QUnit directly, while the individual test modules require QNodeit. The web-based require substitute returns the global QUnit object when a request is made for QNodeit. (As above, all test modules require QNodeit rather than access it directly.)