With Bug 1588861 landed, we have the SpiderMonkey-side work done to cache ES modules. The next steps will be to plumb this into the startupcache / scriptpreloader to call the new APIs.

Putting this in the JavaScript component for now since js-team will probably be the ones who do this work. This races with Bug 1586771 which changes the caching format, but it is probably useful to fix this first.

Bug 1688788 is migrating the ScriptPreloader to Stencil-XDR which will mostly solve this.

:tcampbell, since bug 1688788 has now landed, what else needs to happen here?

prototype integrated with esmification: https://treeherder.mozilla.org/jobs?repo=try&revision=1fdf85abc2e6d73a1989b56e44f235f9a73b1b2a

This adds the parameter to the module loaders evaluation method. I also
rewrote the comments a bit to make this section clearer based on my
understanding of how this works.

Depends on D145555

This is called ComponentModuleLoader rather than ModuleLoader as memory leak
detection doesn't like it if we have more than one class with the same name,
even if they're in different namespaces. Other name suggestions welcome.

Depends on D145556

Depends on D145557

As explained in the bug, we need to dispatch without using the event loop so we
can complete the import synchronously.

Depends on D145558

This will be used to hold compilation results before they are passed to the base class.

Depends on D145560

This is the main patch that finally implements the import.

The derived module loader uses a list of pending load requests to drive the system.

Depends on D145564

Depends on D145565

Sorry, I've uploaded a bunch of patches to the wrong bug.

Comment on attachment 9275156 [details]
Bug 1602931 - Part 3: Add option for synchronous module evaluation in the module loader r?yulia

Revision D145556 was moved to bug 1432901. Setting attachment 9275156 [details] to obsolete.

Comment on attachment 9275157 [details]
Bug 1602931 - Part 4: Add a module loader class skeleton for mozJSComponentLoader to use r?yulia

Revision D145557 was moved to bug 1432901. Setting attachment 9275157 [details] to obsolete.

Comment on attachment 9275158 [details]
Bug 1602931 - Part 5: Give BackstagePass a module loader r?yulia

Revision D145558 was moved to bug 1432901. Setting attachment 9275158 [details] to obsolete.

Comment on attachment 9275160 [details]
Bug 1602931 - Part 6: Give our new module loader an event target that dispatches synchronously r?yulia

Revision D145560 was moved to bug 1432901. Setting attachment 9275160 [details] to obsolete.

Comment on attachment 9275161 [details]
Bug 1602931 - Part 7: Add a load context for use by the new module loader r?yulia

Revision D145561 was moved to bug 1432901. Setting attachment 9275161 [details] to obsolete.

Comment on attachment 9275164 [details]
Bug 1602931 - Part 10: Implement mozJSComponentLoader ImportModule method to synchronously import an ES6 module r?yulia

Revision D145565 was moved to bug 1432901. Setting attachment 9275164 [details] to obsolete.

Comment on attachment 9275165 [details]
Bug 1602931 - Part 11: Add ChromeUtils.importModule method to import and ES6 module r?smaug

Revision D145566 was moved to bug 1432901. Setting attachment 9275165 [details] to obsolete.

Fixed as a part of bug 1432901 patch, by sharing the existing JSM cache code.