[meta] Migrate from Cu.import to ES6 Modules

NEW
Unassigned

Status

()

P3
normal
2 years ago
27 days ago

People

(Reporter: Yoric, Unassigned)

Tracking

(Depends on: 3 bugs, Blocks: 2 bugs, {meta})

Firefox Tracking Flags

(Not tracked)

Details

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.
Keywords: meta
Priority: -- → P3

Updated

2 years ago
Depends on: 1311726

Updated

2 years ago
Depends on: 1311728
Blocks: 1353816
Depends on: 1240072
(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:?]
I believe we were only really expecting memory savings before we moved to the shared JSM global.
(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:?]

Comment 4

a month ago
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.
Ted is already working on a different approach in bug 1432901.

Comment 6

a month ago
(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
(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)
You need to log in before you can comment on or make changes to this bug.