On Sun, Sep 25, 2016 at 12:13:41AM +0200, David Teller wrote:
So, can anybody think of good reason to not do this?
One major problem I see with this is that we currently lazily
import most modules the first time that a symbol they export is
referenced. If we move to CommonJS or ES6 modules, we need to
either:
a) Load essentially *all* of our Chrome JS at startup, before we
even draw the first window. Maybe the static dependency handling
of ES6 modules would make that more tractable, but I'd be
surprised.
b) Manually import modules whenever we need them. That might be
doable in CommonJS or with the proposed future dynamic imports
of ES6, but with a lot of additional cognitive overhead.
c) Use CommonJS, but with a lazy import helper. I wouldn't mind
that approach so much, but I think that it would pretty much
nullify any advantage for static analysis.
or,
d) Some hybrid of the above.
Frankly, I've been considering transitioning the code I work
with to CommonJS for a while, mainly because easier for outside
contributors to cope with (especially if they're used to Node).
Cu.import tends to hide the names of the symbols it exports
(which shows in how often our ESLint hacks fail to guess at what
it exports), and even defineLazyModuleGetter takes some getting
used to.
The main things that have been stopping me are the lack of
support for lazy imports, and the unfortunate impact that the
SDK loader has on debugging, with its mangling of exceptions,
and the source URL mangling imposed by the subscript loader. But
those problems can be overcome.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
