Open Bug 1308512 (esm-ification) Opened 5 years ago Updated 18 days ago

[meta] Migrate from Cu.import to ES6 Modules

Categories

(Core :: XPConnect, task, P3)

task

Tracking

()

People

(Reporter: Yoric, Unassigned)

References

(Depends on 18 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.
Keywords: meta
Priority: -- → P3
Depends on: 1311726
Depends on: 1311728
Blocks: 490147
Depends on: modules-0
Depends on: 1453559
(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:?]
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.
(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)
Depends on: 1608269
Depends on: 1608271
Depends on: 1608272
Depends on: 1608273
Depends on: 1608274
Depends on: 1608275
Depends on: 1608276
Depends on: 1608277
Depends on: 1608278
Depends on: 1608279
Depends on: 1608281
Depends on: 1608282
Alias: esm-ification
Type: defect → task
Depends on: 1609269
Depends on: 1609271
Depends on: 1610653
Depends on: 1611229
Depends on: 1692217
You need to log in before you can comment on or make changes to this bug.