Thunderbird will eventually remove jsm modules and replace them with ESM modules. The thunderbird core code already avoids using the jsm modules itself (but apparently they still exist). I did find a backwards-compatible replacement pattern in Günter Gersdorf's "copy sent to current" Add-on during a review. It goes like this:
var { AppConstants } = ChromeUtils.importESModule(
"resource://gre/modules/AppConstants.sys.mjs"
);
var ESM = parseInt(AppConstants.MOZ_APP_VERSION, 10) >= 128;
var { ExtensionCommon } = ESM
? ChromeUtils.importESModule("resource://gre/modules/ExtensionCommon.sys.mjs")
: ChromeUtils.import("resource://gre/modules/ExtensionCommon.jsm");
Here I am basically using the application version to trigger the new code (which utilizes CU.importESModule()) - even though it slightly complicates the code, it will guard against bad surprises should Mozilla / Tb decide to remove the jsm files at any stage during esr128.
My plan is to remove the pattern next year and make the next version compatible with esr128 and esr140, deprecating support for esr115 from that point forward. This will make the code easier to read again and still support "legacy" users.
Thunderbird will eventually remove jsm modules and replace them with ESM modules. The thunderbird core code already avoids using the jsm modules itself (but apparently they still exist). I did find a backwards-compatible replacement pattern in Günter Gersdorf's "copy sent to current" Add-on during a review. It goes like this:
Here I am basically using the application version to trigger the new code (which utilizes
CU.importESModule()
) - even though it slightly complicates the code, it will guard against bad surprises should Mozilla / Tb decide to remove the jsm files at any stage during esr128. My plan is to remove the pattern next year and make the next version compatible with esr128 and esr140, deprecating support for esr115 from that point forward. This will make the code easier to read again and still support "legacy" users.