Re: ES Modules in Content Scripts

Hello again,

I was putting together an explainer for my followers on Twitter about the
latest version of my extension, and I thought the reference image I used in
one part of it sums up the benefits of modules in a screenshot. Pictures
are worth a thousand words, so I figure it would be beneficial to enter it
for the record here as well.

https://i.imgur.com/sHYJ7vX.png

Kind regards,
Adaline Simonian
she/her


On Tue, Dec 17, 2019 at 6:25 AM Rob Wu <rob@robwu.nl> wrote:

> Hi Adaline,
>
> Firefox is not actively working on supporting ES6 modules in content
> scripts, but has the following open issues to track this feature:
> - https://bugzilla.mozilla.org/show_bug.cgi?id=1451545
> - https://bugzilla.mozilla.org/show_bug.cgi?id=1536094 (about dynamic
> imports)
>
> Chromium does not have an issue on their issue tracker or in their chromium-extensions
> mailing list
> <https://groups.google.com/a/chromium.org/forum/#!forum/chromium-extensions>,
> so I am adding Simeon (extension developer advocate at Google) to the
> conversation to see where they are at. Simeon, is (dynamic) module support
> in content scripts part of your roadmap?
>
> Kind regards,
>  Rob
>  https://robwu.nl
>
>
> Op di 17 dec. 2019 om 04:41 schreef Florian Rivoal <florian@rivoal.net>:
>
>> Hello Adaline,
>>
>> The needs you express in your mail seem very legitimate to me, and this
>> certainly sounds like something that should at least be explored.
>>
>> However, as you have noticed, this group has become inactive. I still
>> think that browser extensions ought to be standardized fully, but
>> unfortunately at the best of times this group barely reached critical mass
>> to function, and eventually couldn't hold up. I don't think anybody is
>> opposed to the work happening, but not enough people could commit the time
>> to make it work.
>>
>> If this email of yours here doesn't catch the attention of browser
>> vendors (and give how quiet it's been, I suspect it might not), I'd suggest
>> you try do some out-reach in various venues on this topic. You can try
>> social media in general to recruit more people to your cause in order to
>> prove that this is a pressing need, you can try the various browsers bug
>> trackers to request the feature, and you can have a go at
>> https://discourse.wicg.io/ which is a place within w3c used to propose
>> ideas "to the crowd" and see what sort of feedback you get.
>>
>> I realize this is likely to be a lot of work, and had this community been
>> active, reaching out here would have been the right thing to do, and likely
>> simpler. But it's not, so here we are.
>>
>> Wishing you the best of luck
>> —Florian
>>
>> On Dec 15, 2019, at 12:22, Adaline Simonian <adalinesimonian@gmail.com>
>> wrote:
>>
>> Hello,
>>
>> I see this group has largely gone silent in its online presence so I hope
>> this email doesn't fall through the cracks. I hope y'all are still around
>> and doing well!
>>
>> ES modules have been available in both Chrome and Firefox for some time
>> now - Chrome has supported dynamic imports since version 63 and Firefox
>> since 67, and the upcoming Chrome release (80) also brings module support
>> to workers.
>>
>> Content scripts, however, have been largely neglected. Unlike background
>> pages, browser actions, page actions, and options pages, where you can just
>> set type="module" on a script tag, content scripts remain the sole part of
>> the extension format where you cannot use ES modules at all. You can *kind
>> of* work around the issue by injecting a type="module" script tag into
>> the target page and using web-accessible resources, but you lose access to
>> all the layers of separation and the APIs available to content scripts..
>> You can't reclaim the separation given to content scripts, and you can only
>> regain the API access by means of a huge amount of implementation overhead
>> to use messaging between the injected scripts and background scripts to
>> play a game of telephone with the APIs.
>>
>> From a spec point of view, it doesn't seem to be such a hard problem to
>> crack on the surface in a backwards-compatible fashion: consider, for
>> example, an additional property in the manifest under "content_scripts"
>> such as "js_modules", which would function just as "js" functions now but
>> with the distinction that any entry in the "js_modules" array is added to
>> the respective context as a module, hence allowing the use of `import` and
>> `exports` without resorting to 3rd party tooling that can bloat what may
>> otherwise be a relatively clean and dependency-limited extension.
>>
>> With the current state of support that Firefox and Chrome, the two
>> largest supporters of the browser extensions standard, have for current ES
>> syntax and functionality, it only seems natural to allow content scripts to
>> be organised as modules. Currently I'm authoring an extension for Firefox
>> where I've been able to completely write dependency-free code using modern
>> syntax. The only place where I'm hitting a hard limit is content scripts.
>>
>> Of course, updating the spec is no substitute for implementation work,
>> but implementation work can't happen without corresponding work on the spec.
>>
>> Hope to hear from you!
>>
>> Kind regards,
>> Adaline Simonian
>> she/her
>>
>>
>>