#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.
Arend modules are loaded via
<script> tags. Modules must be loaded in dependency order.
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.
In Node, modules are located both in
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).
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.)