W3C home > Mailing lists > Public > public-browserext@w3.org > December 2019

ES Modules in Content Scripts

From: Adaline Simonian <adalinesimonian@gmail.com>
Date: Sat, 14 Dec 2019 19:22:09 -0800
Message-ID: <CANo6sdHaWOxzeDf9SEw0TFGwXQbbY=tC7kHSrbvZNNtF9ojbsw@mail.gmail.com>
To: public-browserext@w3.org
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
Received on Monday, 16 December 2019 12:33:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:03 UTC