Ideally, it would be great to replace our current messy module loading with something stricter. I suspect, however, that we have subtleties that won't let us proceed. Let me detail a bit some of the problems that might occur if we wish to rewrite existing code with a stricter module loader.
* Side-effects For one thing, I remember that some of our JS code defers loading its dependencies (typically, using `XPCOMUtils.lazyModuleGetter`) to make sure that this specific module is loaded after some startup code has been properly initialized. I don't remember the specifics, but I recall having seen it in or around Services.jsm. I also recall that it is necessary for some tests that mockup XPCOM components, so we need to ensure that the XPCOM components have time to be installed before the code that depends upon them actually instantiates them. I suspect that this hairy behavior is quite the opposite of what ES6 modules are for, and that this may make it impossible to use them in this context. * Blocking C++ while JS code is being loaded It is pretty common for C++ code to call JS code – typically, without knowing that it's JS, thanks to XPCOM/XPConnect, expecting it to be a regular function/method call. If executing this JS code means that we need to somehow load modules, this means that the loading needs to block the caller. Is this the case already? Cheers, David On 26/09/16 12:33, jcoppe...@mozilla.com wrote: > On Sunday, 25 September 2016 07:32:32 UTC+1, David Teller wrote: >> What's the current status of the implementation of ES6 modules? > > ES6 modules are supported for chrome code, but not yet for content (pending > spec related discussions that are not relevant for chrome). > > It would be great if we could moving to using standard ES6 modules > internally! If anyone is interested on working on converting the codebase > then I can help with this. > > Can you explain the requirement for synchronous loading? With ES6 modules > all imports are determined statically and are loaded before the script is > executed, and the spec does not currently provide an API to load a module, > synchronously or otherwise. > > Jon > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
