Re: ES Modules in Content Scripts

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