Module Execution Order

Claus Reinke claus.reinke at
Wed Apr 10 08:44:26 PDT 2013

>> 1)  Just to be explicit, this is a different execution order than
>> node/CommonJS modules.  Nothing wrong with that, just pointing it out.
> Yes.

Execute-in-order-of-import is used in practice to emulate parameterized
modules (for instance, set a global config, *then* import RequireJS).

As long as executing a module cannot change its set of exports, only
the value of exports, it should be possible to separate the binding
phase (topological sorted, establish import bindings) from the 
execution phase.

If the execution phase is to use the same order as the binding phase,
a suggested alternative to the parameterized modules pattern should 
be documented. 

For simple parameterized modules, that would involve an exported
setter, called after the imported module is executed.

For RequireJS-like uses, that would involve separate module loader
phases (first phase, load RequireJS-like import; second phase, configure
RequireJS and use for loading rest of dependencies).

Most likely, the classic use of modules as executable scripts should be 
discouraged, in favour of modules as declarative providers of bindings.

>> 2)  The execution order is then just a topological sort of the dependency
>> graph, breaking cycles where appropriate.  Is that correct?
> Yes.  Cycles are broken by reference to the order in which the
> relevant imports appear in the source of the importing module.

More information about the es-discuss mailing list