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 foo
inside 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.jsm
to 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.