nagai/fune
3
0
Fork 0
forked from mirrors/gecko-dev
Code Pull requests Activity

Bug 1806331 - doc: use ChromeUtils.importESM instead of ChromeUtils.importESModule r=Standard8 DONTBUILD

Browse source 
Differential Revision: https://phabricator.services.mozilla.com/D165815
This commit is contained in:
Sylvestre Ledru 2023-01-03 18:47:59 +00:00
parent 7c6fecd0a3
commit 13ac309924
1 changed files with 2 additions and 2 deletions
repo.diff.show_diff_stats Download patch file Download diff file Expand all files Collapse all files

4
docs/code-quality/lint/linters/eslint-plugin-mozilla/reject-import-system-module-from-non-system.rst
View file

@ -6,7 +6,7 @@ modules.
Using static import for a system module into a non-system module would create a separate instance of the imported object(s) that is not shared with the other system modules and would break the per-process singleton expectation.
The reason for this is that inside system modules, a static import will load the module into the shared global. Inside non-system modules, the static import will load into a different global (e.g. window). This will cause the module to be loaded into different scopes, and hence create separate instances. The fix is to use ``ChromeUtils.importESM`` which will import the object via the system module shared global scope.
The reason for this is that inside system modules, a static import will load the module into the shared global. Inside non-system modules, the static import will load into a different global (e.g. window). This will cause the module to be loaded into different scopes, and hence create separate instances. The fix is to use ``ChromeUtils.importESModule`` which will import the object via the system module shared global scope.
Examples of incorrect code for this rule:
@ -25,7 +25,7 @@ Inside a non-system module:
.. code-block:: js
const { AppConstants } = ChromeUtils.importESM(
const { AppConstants } = ChromeUtils.importESModule(
"resource://gre/modules/AppConstants.sys.mjs"
);