Open
Bug 1308512
(esm-ification)
Opened 8 years ago
Updated 1 year ago
[meta] Migrate from ChromeUtils.import to ES6 Modules
Categories
(Core :: XPConnect, task, P3)
Core
XPConnect
Tracking
()
NEW
People
(Reporter: Yoric, Unassigned)
References
(Depends on 10 open bugs, Blocks 1 open bug, )
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
|
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•5 years ago
|
Updated•5 years ago
|
Alias: esm-ification
Updated•5 years ago
|
Type: defect → task
Updated•3 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
|
Severity: normal → S3
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•