Description

ESM has been available in all major browsers through HTML's <script type="module"> for years now and more recently in Workers and Worklets, however JS execution in browsers is not limited to these contexts.

This issue is about improving interoperability for ESM in contexts where browser support is partial, that is to say, other types of documents (XHTML, SVG) and specialized types of worker (Service Workers).

Contexts without any known integration effort for ESM, such as content scripts, would not be included in this proposal.

Specification

See https://tc39.es/ecma262/#sec-modules for the main spec defining modules though this issue is more about their integration in multiple other consuming specs (see links below)

Additional Signals

Site Breakage and Workaround

Classic JS scripts and JS module scripts (or ESM for short) are two types of scripts with incompatible grammars and different sets of features. While support for some new features (static imports, top-level await...) is restricted to ESM, ESM is not yet available everywhere in browsers, making writing or consuming isomorphic code difficult. For example, one cannot write a module that works in all browsers both in a HTML document, a XHTML document, a SVG document and a Service Worker. Without transpilation, the workaround is often using classic scripts and not benefiting from these newer syntax-enabled features, as they are not really polyfillable and detecting support for them is not straightforward. Of course the other way is not targeting some browsers at all 😢

Integration specs, existing tests, documentation and browser bugs

This issue is about improving interoperability for ESM in contexts where browser support is already partial, such as:

• <script type="module"> in HTML documents with XML syntax (aka XHTML documents)
  • WHATWG spec: https://html.spec.whatwg.org/multipage/scripting.html#attr-script-type
  • WPT: TBD
  • Blink bug (30 stars): https://issues.chromium.org/issues/40518469
  • Webkit bug: TBD
  • Implementations: Gecko
• <script type="module"> in SVG documents
  • W3C spec: https://svgwg.org/svg2-draft/interact.html#ScriptElement
  • WPT: https://wpt.fyi/results/svg/interact/scripted/module-01.svg
  • MDN documentation: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/script
  • Blink bug: TBD
  • Gecko bug (resolved): https://bugzilla.mozilla.org/show_bug.cgi?id=1839954
  • Webkit bug: TBD
  • Implementations: Gecko
• type: "module" for Service Workers registered via ServiceWorkerContainer.register(...)
  • W3C spec: https://w3c.github.io/ServiceWorker/#navigator-service-worker-register
  • WPT: https://wpt.fyi/results/service-workers/service-worker/registration-script-module.https.html , https://wpt.fyi/results/service-workers/service-worker/registration-scope-module-static-import.https.html
  • Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1360870
  • Implementations: Blink, Webkit
• "type": "module" for background scripts defined via the "background.service_worker" key in Web Extension Manifests
  • WECG spec (incomplete): https://w3c.github.io/webextensions/specification/index.html#key-background
  • WPT: TBD
  • Chrome documentation: https://developer.chrome.com/docs/extensions/reference/manifest/background
  • MDN documentation: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/background
  • Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1775574
  • Implementations: Blink, Webkit

Out of scope features

Contexts without enough signal from browsers to integrate ESM in them would not be included in this effort, such as:

• scripts executed via WorkerGlobalScope.importScripts(...) in Workers
• content scripts executed via {browser,chrome}.{scripting,tabs}.executeScript(...) in Web Extensions
• content scripts defined via the "content_scripts" key in Web Extension Manifests
• API scripts defined via the "user_scripts.api_script" key in Web Extension Manifests
• background scripts defined via the "background.scripts" key in Web Extension Manifests
• dynamic import(...) in Service Workers ( see How should import() work in service workers? w3c/ServiceWorker#1585 )