The main module serves the crucial purpose of combining all the exports of
other modules in the package, which eliminates the need for api.export in
principle, though the module.exports of the main module (also defined as
Package[packageName]) will still be populated with any api.export-ed
properties.
It's possible to use the modules package without using the ecmascript
package (if all you want is a CommonJS require/exports module system), but
I can't imagine anyone wanting ES2015 without a module system.
In case you need persuading, I recently gave a talk about why
import/export are so important: benjamn.github.io/empirenode-2015
When used, the 'modules' package provides a CommonJS require/exports
module system via the exported meteorInstall function. Once that
underlying system is available, ECMAScript 2015 import/export syntax can
be easily compiled into require/exports.
The comments for inBareFiber claim that it's for times when you don't want
to inherit the dynamic environment variables of the current Fiber, but
none of the call sites actually relied on this behavior. Still, it may be
worth noting that async functions automatically (and cheaply) inherit the
calling Fiber's dynamics, which is virtually always what you want.
Any code that has access to a Future object also has the capability of
calling its .return method. Promise objects, by contrast, can only be
resolved or rejected by the creator of the Promise (or any code granted
access to the special resolve and/or reject functions, which are not
simply methods of the Promise object). The run-app.js file contains a lot
of code that used to assume a Future could be resolved by anyone, which is
why the _{make,resolve}Promise methods were necessary.
For this reason, replacing Future with Promise in these two files seemed
tricky and worth attempting first, before spending time converting easier
files.
