This document shows a possible migration path from Cu.import() to ES modules for the code of Firefox.
- Preserve current JSM semantics where multiple imports of a single module from different globals results in a single module instance that lives in a separate global to the importer.
- Add-ons and Thunderbird should not be affected by the migration.
- Memory usage should not be adversly affected.
- Optionally, transition all JSMs to use a single global (bug 1186409) ahead of time to flush out any issues.
- Implement an internal API to synchronously load an ES module into a specified global.
- Make
Cu.import()use the above to optionally load an ES module based on the file extension. - Inform developers that they should now use ES6 modules instead of jsm for their new code.
- Reject patches that introduce new jsm modules. Optionally, patch mozReview to do this automatically.
This section refers to imports inside a module, not at top-level. Top-level imports must continue to use Cu.import() to get the module imported into the special shared global as per requirement 1. We might want to disable loading top-level modules in chrome altogether.
- Inform developers that they should now use
import fooinside modules, rather thanCu.import(). - Reject patches that introduce new instances of
Cu.import()inside modules. Optionally, patch mozReview to do this automatically. - Start migrating use of
Cu.import('foo')in modules toimport foo. Add shimfoo.jsmto allow existing cases to continue to work. It should be possible to automate this.
At this stage, we will still have the following cases to contend with:
- conditional imports;
- scoped imports and imports from within a function.
- uses of
XPCOM.defineLazyModuleGetter;
We probably want to wait until there is a programmatic way of loading ES modules added to the spec and then implement that.
@Jonco I don't think we should
This would essentially require us to debug all of Firefox at once, rather than one-step-at-a-time.