(In reply to Tooru Fujisawa [:arai] from comment #3) > :hjones, can I have your input here? > > Apparently the situation around the reusable component went unexpected way, where it breaks the invariant for the module loaders. > > What's the expected usage of those modules? Why there are two types of consumers for those modules? > * `<script type="module">` > * `ChromeUtils.importESModule(..., {global: "current"})` Hi :arai - sorry for the slow reply, I missed the original needinfo. I think our preference for developer experience/ease of use would be to stick with the sync loader-backed auto loading of the custom element code via tag name - provided there are no performance or other concerns associated with that solution. I think we've ended up with two types of consumers for those modules for a couple reasons: * code that was written before the work in bugs 1803810 and 1803678 and therefore had to use `<script type="module">` and never got refactored * lack of developer awareness of the code that auto imports the elements in `customElements.js` To compliment what you're working on in 2020605 we could feasibly implement a custom ESLint rule to warn developers against using `<script type="module">` for any elements in [this array](https://searchfox.org/firefox-main/rev/0894e095dfb46b6dac785365432791a54861fe09/toolkit/content/customElements.js#809) + undertake removing any unnecessary `<script type="module">` tags. Does that sound like a reasonable path forward to you?
Bug 2018794 Comment 22 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Tooru Fujisawa [:arai] from comment #3) > :hjones, can I have your input here? > > Apparently the situation around the reusable component went unexpected way, where it breaks the invariant for the module loaders. > > What's the expected usage of those modules? Why there are two types of consumers for those modules? > * `<script type="module">` > * `ChromeUtils.importESModule(..., {global: "current"})` Hi :arai - sorry for the slow reply, I missed the original needinfo. I think our preference for developer experience/ease of use would be to stick with the sync loader-backed auto loading of the custom element code via tag name - provided there are no performance or other concerns associated with that solution. I think we've ended up with two types of consumers for those modules for a couple reasons: * code that was written before the work in bug 1803810 and bug 1803678 and therefore had to use `<script type="module">` and never got refactored * lack of developer awareness of the code that auto imports the elements in `customElements.js` To compliment what you're working on in 2020605 we could feasibly implement a custom ESLint rule to warn developers against using `<script type="module">` for any elements in [this array](https://searchfox.org/firefox-main/rev/0894e095dfb46b6dac785365432791a54861fe09/toolkit/content/customElements.js#809) + undertake removing any unnecessary `<script type="module">` tags. Does that sound like a reasonable path forward to you?
(In reply to Tooru Fujisawa [:arai] from comment #3) > :hjones, can I have your input here? > > Apparently the situation around the reusable component went unexpected way, where it breaks the invariant for the module loaders. > > What's the expected usage of those modules? Why there are two types of consumers for those modules? > * `<script type="module">` > * `ChromeUtils.importESModule(..., {global: "current"})` Hi :arai - sorry for the slow reply, I missed the original needinfo. I think our preference for developer experience/ease of use would be to stick with the sync loader-backed auto loading of the custom element code via tag name - provided there are no performance or other concerns associated with that solution. I think we've ended up with two types of consumers for those modules for a couple reasons: * code that was written before the work in bug 1803810 and bug 1803678 and therefore had to use `<script type="module">` and never got refactored * lack of developer awareness of the code that auto imports the elements in `customElements.js` To compliment what you're working on in bug 2020605 we could feasibly implement a custom ESLint rule to warn developers against using `<script type="module">` for any elements in [this array](https://searchfox.org/firefox-main/rev/0894e095dfb46b6dac785365432791a54861fe09/toolkit/content/customElements.js#809) + undertake removing any unnecessary `<script type="module">` tags. Does that sound like a reasonable path forward to you?