Avoid exporting "ready" promise on the module object

[sbc100]

I believe the "ready" promise was set on the Module object here primarily so that closure would not minify the name. Instead of polluting the Module namespace we can instead just tell closure not to minify it.

In addition to polluting the Module namespace exporting a ready promise is also confusing since the only way to get a module object when -sMODULARIZE is used is via waiting on the promise returned from the factory function. So, by definition, the promise has already resolved before anyone can access it.

Instead we use the closure-externs.js file to suppress the minifiction which matches the behavior of the incoming moduleArg argument.

[kripken]

I am not sure if there is not another use for .ready in ES6 modules or CommonJS or something else, but lgtm if @brendandahl confirms no problem there.

[sbc100]

I am not sure if there is not another use for .ready in ES6 modules or CommonJS or something else, but lgtm if @brendandahl confirms no problem there.

I'm pretty sure there would be no way to call access Module.ready unless you had already resolve the promise returned by the module factory function.

[brendandahl]

You could technically get access to ready before the promise is resolved since the you can pass in an argument to the ModuleFactory that will then set ready on the argument. e.g.

let m = require('./a.out.js');
let settings = {};
m(settings);
console.log(settings.ready);
// main wouldn't run until next tick

Anyway, I don't really see a need for defining it on the module and returning it from the ModuleFactory for modularize/es6.

[sbc100]

You could technically get access to ready before the promise is resolved since the you can pass in an argument to the ModuleFactory that will then set ready on the argument. e.g.

let m = require('./a.out.js');
let settings = {};
m(settings);
console.log(settings.ready);
// main wouldn't run until next tick

Very tricky yes. I wonder if we should remove that feature? i.e. should we moduleArg as purely readonly and then Object.assign(Module, moduleArg)

Anyway, I don't really see a need for defining it on the module and returning it from the ModuleFactory for modularize/es6.

Agreed. I think this should be fine to land.

[curiousdannii]

This probably warrants a mention in the changelog.