\o/, let's join forces :) I admit that I haven't thought at all about the impact on exceptions. If we migrate to ES6 modules, then the problem is something that we don't need to handle. If we migrate to CommonJS modules with a loader built into XPConnect, I think that we can solve this without blood or pain. More on this later.
I'm not entirely scared of lazy modules. There are obvious difficulties, but I don't think that they are insurmountable. I'll answer separately for CommonJS and ES6 modules, because the problems we'll be facing are clearly different. * CommonJS As you mention in c), I'm pretty sure that we can trivially port `defineLazyModuleGetter` to CommonJS, without changes to the client code. See [1] for a few more details. This will not be sufficient to get static analysis to understand lazy imports, but I imagine that we can fix this as follows: 1. Introduce a `lazyRequire` function with the same signature and scope as `require` and with the semantics of `defineLazyModuleGetter`. 2. Either teach our open-source linters that `lazyRequire` is `require` or use Babel to rewrite `lazyRequire` to `require` before static analysis. * ES6 modules Indeed, ES6 modules don't like lazy imports. Theoretically, we could port `defineLazyModuleGetter` using `processNextEvent` footgun magic, but I would really hate to go in this direction. I have put together in [2] a possible plan to migrate to ES6 modules without breaking `defineLazyModuleGetter` – pending confirmation from @jonco that this can be done. Essentially, past some point in the migration, `Cu.import` becomes a sync version of the ES7's `import()` function. If this works (and it's a pretty big "if"), we can use more or less the same steps as above. Cheers, David [1] https://gist.github.com/Yoric/777effee02d6788d3abc639c82ff4488 [2] https://gist.github.com/Yoric/2a7c8395377c7187ebf02219980b6f4d On 28/09/16 00:42, Kris Maglione wrote: > 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
