Open
Bug 1308512
(esm-ification)
Opened 8 years ago
Updated 4 days ago
[meta] Migrate from ChromeUtils.import to ES6 Modules
Categories
(Core :: XPConnect, task, P3)
Core
XPConnect
Tracking
()
NEW
People
(Reporter: Yoric, Unassigned)
References
(Blocks 2 open bugs, )
Details
(Keywords: meta)
Based on the following conversation on dev-platform: https://groups.google.com/d/msg/mozilla.dev.platform/JhmCjt3fnP0/10RRHJtvBAAJ Migrating away from Cu.import and to a more standard module system would be useful to: 1/ save lots of memory; 2/ make our code much more friendly to static analysis; 3/ make it simpler for contributors. A strategy has been devised to migrate towards ES6 modules: https://gist.github.com/Yoric/d271066aa4a4484602e817412957a1ff, without breaking compatibility with add-ons/Thunderbird/SeaMonkey and without require us to migrate everything at once.
Reporter | ||
Updated•8 years ago
|
Blocks: js-analysis
Comment 1•6 years ago
|
||
(In reply to David Teller [:Yoric] (away until end of July - please use "needinfo") from comment #0) > Migrating away from Cu.import and to a more standard module system would be > useful to: 1/ save lots of memory; David I skimmed the dev-platform thread but it's not totally clear to me, what kind of memory savings are you expecting over JSMs? It would be helpful to get an estimate to help prioritize this work in the context of Fission MemShrink.
Flags: needinfo?(dteller)
Whiteboard: [overhead:?]
Comment 2•6 years ago
|
||
I believe we were only really expecting memory savings before we moved to the shared JSM global.
Comment 3•6 years ago
|
||
(In reply to Kris Maglione [:kmag] from comment #2) > I believe we were only really expecting memory savings before we moved to > the shared JSM global. Okay, lets unblock 1353816 then.
No longer blocks: 1353816
Whiteboard: [overhead:?]
Since legacy extensions are no longer supported, I put together a simplified plan at: https://gist.github.com/Yoric/d271066aa4a4484602e817412957a1ff#gistcomment-2646825, which optionally depends on bug 1342012 if we decide on allowing the dynamic `import(…)` to be used in JSMs to import ES6 modules, which would vastly simplify things and allow us to WONTFIX bug 1311728¹. ¹ The implementation of bug 1311728 would be non‑standard and likely fragile, and so I prefer bug 1342012.
Comment 5•6 years ago
|
||
Ted is already working on a different approach in bug 1432901.
(In reply to Kris Maglione [:kmag] from comment #5) > Ted is already working on a different approach in bug 1432901. Then we add that as a blocker to this.
Depends on: 1432901
Reporter | ||
Comment 7•6 years ago
|
||
(In reply to Kris Maglione [:kmag] from comment #2) > I believe we were only really expecting memory savings before we moved to > the shared JSM global. Yes, that was the idea. Sorry for the slow answer, I was on PTO.
Flags: needinfo?(dteller)
Updated•4 years ago
|
Updated•4 years ago
|
Alias: esm-ification
Updated•4 years ago
|
Type: defect → task
Updated•2 years ago
|
Summary: [meta] Migrate from Cu.import to ES6 Modules → [meta] Migrate from ChromeUtils.import to ES6 Modules
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
See Also: → tb-esm-ification
Updated•1 year ago
|
Comment 8•23 days ago
|
||
Dropping bug 1525652 as the remaining parts there are common js -> ES modules, which don't affect the JSM -> ES modules part.
No longer depends on: 1525652
Comment 9•23 days ago
|
||
Also changing this to be blocking bug 1776174 rather than depending on, as the work to transition is almost done, and we'll handle the clean ups as part of bug 1776174.
You need to log in
before you can comment on or make changes to this bug.
Description
•