how to account for asynchronous exports?

[jokeyrhyme]

The main weakness in using return at the bottom of a definition to declare the exports is that this is synchronous. If your module needs to do asynchronous work in order to initialise itself, you inevitably end up having to expose that asynchronous nature to other modules that depend on it (by exporting callbacks or promises).

I think return is still great syntax for wholly-synchronous modules.

One example of an asynchronous module is a module that always needs to perform an XMLHttpRequest during its initialisation, where it is highly convenient for all other client modules to be wholly-synchronous (no desire for asynchronous-ness to spread like a virus through the rest of the modules).

Should we consider these out of scope for the module system? If there are, indeed, within the scope, how do we asynchronously declare the exports of a module at a later time?

As Promise is now part of ES6, could we just return the Promise and have the module system automatically wait for its resolution prior to sharing the exports with other modules?

[jrburke]

I think it is out of scope for a module system, better to just use a promise as the export value, and have code that uses it use then() to interact with it. I see a module system more like being able to refer to functions and objects defined in different files. You could override the loader hooks though to provide some way to do this, but feel it is more appropriate as a useland thing.

Also I did not mean for the issues to be enabled on this repo, it was a throw-away thing. So I may try to turn it off, apologies if this messes up this issue.