Convert loader to ES6 modules targeting Gecko 115

[MrOtherGuy]

Firefox team is working on converting old custom .jsm modules to standard ES6 modules. As a part of that, I would like this autoconfig project to do the same.

For regular custom scripts this shouldn't change anything, however, it would change a bit how we load the boot.jsm module and it can affect how custom scripts that are marked as backgroundmodule are loaded. The relevant function ChromeUtils.importESModule() should be available in Firefox 103 I believe.

What I'm wondering is we should start using ES6 modules when 103 releases, or only after those APIs become available in ESR.

I have had a local test setup in Nightly that uses ES6 module loading and it seems to pass all the current (albeit still quite limited) tests. That setup currently works like this:

• config.js loadsboot.sys.mjs using ChromeUtils.importESModule()
• boot module can now import both .sys.mjs files as well as old style .uc.js files.
• .sys.mjs files are automatically imported as ES6 modules and they are always treated as backgroundmodule
• All .uc.js files are treated like before. I'm not sure if this can or should be changed. Needs some investigating.

This would then allow custom .sys.mjs files to use standard import statements to load symbols from sub-modules and even from each other.

But if possible I would like to not break ESR102 so we would need to do se feature checking and possibly even splitting boot.j into two versions and I'm not super into doing that.

[MrOtherGuy]

Alright, so status: I added support for loading *.sys.mjs files as ES6 modules in c4e73f9aed8fe601f3d7a0b3b835576f20b158eb

However, you can only use those in Firefox 104 onwards (103 probably, I didn't test that though). Your old files should work as is, no changes required.

The main config.js (in program folder) is not changed at this time. Only thing I plan to do for that currently is to make it use ChromeUtils.import instead of Cu.import but that can't be done until ESR 102 is the main ESR release.

Loading boot.jsm itself as ES6 module would be neat, but like I stated previously it will not work in 102 and thus ESR would be unsupported. If ChromeUtils.importESModule() gets uplifted to ESR 102 line then we can totally do that though.

[MrOtherGuy]

Also, when config.js is eventually changed to load the main boot module as ES6 module, then we might as well remove getting { Cu, Ci, ... } = Components since Cu, Ci, etc. variables should be available anyway.

[MrOtherGuy]

Status of this is that I intend to keep boot module as old .jsm until next ESR (112?). That is, unless there is some change in Firefox that forces us to use ES6 module loading in some release before then.

[MrOtherGuy]

So, next ESR is actually based on Firefox 115 and with that now being released I'm gonna land a change soon-ish for fx-autoconfig version labeled as "0.8".

"0.8" will not be compatible with old 102 ESR which doesn't have functionality to load ES6 modules.

There's bunch of internal changes, but the only changes that might break your custom scripts should be:

• deprecation of old filesystem helpers like _ucUtils.readFile() - these were left there in "0.7" alongside of newer _ucUtils.fs. API but the old ones are now fully gone.
• _ucUtils.prefs.get() now return objects containing the value of the pref - see prefs section in readme

[MrOtherGuy]

With last couple of changes and loader version 0.8 this now requires support for ES6 modules in chrome context. So with that Gecko 102 support is dropped.

I have tested bunch of things in Firefox 115, but there's probably remaining issues so feel free to report them. I have NOT tested Thunderbird 115 yet though so there's rather a good chance it would break there in one way or another.

[MrOtherGuy]

TB 115 seems to be working alright now too - so this is done