Esmify

[trickypr]

See: https://docs.google.com/document/d/1cpzIK-BdP7u6RJSar-Z955GV--2Rj8V4x2vl34m36Go/edit#

[ajvincent]

<tldr>I have no technical problems with this patch, but I'm worried about breaking esr102.</tldr>

😅 I'm in the middle of a complete configuration rewrite on the multisource-20220106 branch (which I now realize should've been called 20230106... oops). This includes a significant change to how we generate and manage user source directories.

So this patch will need to be migrated to cleanroom/source on the "multisource" branch as well, which is very unstable right now. I'm pretty sure cleanroom/source is the new home for template source, but the existing source directory will go away when the branch lands. ETA for the branch landing is the end of January, 2023.

I've loosely followed the ECMAScript module porting effort, and I'm generally in favor of it. Maybe it'll lead to TypeScript modules in Mozilla code. 😛

The only thing preventing me from rubber-stamping this pull request is a question about whether Extended Support Release 102 would continue working with this. I want to support ESR sources as long as Mozilla does, which is about 14 months (15 to allow a month transition off the very last ESR minor release for a series).

Basically, I don't know off the top of my head when this effort started. If it isn't safe for 102, then this pull request has to hold until the end of August, 2023.

https://spidermonkey.dev/areweesmifiedyet/ implies ESMification started immediately after the ESR 102 release (2022-06-28 per the Firefox release calendar).

So, I think instead of approving this patch immediately, we should talk about a branching for esr102. I would like to hold this pull request and an esr102 branch until after my big configuration rewrite lands, please.

Alex

[trickypr]

I am fine with holding this until you think it is good to merge. Note that anyone using the devtools from 108 onwards will need this patch though (bug 1796582 is to blame).

[ajvincent]

sigh

Then #27 becomes more important, and I'd welcome a patch establishing at least an initial policy there.

[ajvincent]

I asked yesterday on chat.mozilla.org in the #developers channel about ESMification, and this pull request definitely won't work on ESM 102:

also, ChromeUtils.defineESModuleGetters doesn't work there (bug 1768870)

https://matrix.to/#/!lrZtdjyLpBmoKbMdyx:mozilla.org/$At1mEOUAsyT2op8nG7UV6pwJUop4FpwzYDJ5cumRo5s?via=mozilla.org&via=matrix.org&via=igalia.com

[trickypr]

With regards to versioning, is it possible that we follow Mozilla. So, we have a main branch that revives new features and is bound to the latest stable and we maintain ESR branches for the last ESR where we only land bug fixes?

So, because this PR is primarily a dev experience improvement rather than a bug fix, this would be merged into the latest stable, and then included in the next ESR.

[ajvincent]

I was thinking the same thing: after landing my multisource branch, I was going to create a esm102 branch where, if we wanted to land this, it wouldn't land as-is on the branch.

[ajvincent]

I've created an esm102 branch, so you can revise this for a review without impacting that branch.