1 of 13

ES Module Attributes

Status update

Myles Borins, Google

Daniel Ehrenberg, Igalia in partnership with Bloomberg

Sven Sauleau, Babel

Daniel Clark, Microsoft

2 of 13

ES Module attribute

Pass more information alongside the module specifier, with an initial aim to support non-JS ES module types. As of this moment the standardization of other module types is blocked. This includes:

  • JSON Modules
  • CSS Modules
  • HTML Modules*
  • WASM Modules*

*Depending on the design

3 of 13

Proposed syntax

import json from "./foo.json" as "json";

  • More ergonomic and simple; form of `with type: "json"`

4 of 13

Update to dynamic import (part of this proposal)

import("foo.json", "json")

Second argument is the Module type of foo.json

5 of 13

Proposed Web API (Separate Web proposal)

new Worker("foo.wasm", { as: "webassembly" })

Cannot use type as workers already utilize that property.

6 of 13

AsClause may be extended for more constant types

"ASI hazard" case is unlikely (\nas\n)

7 of 13

Other keywords to consider

import json from "./foo.json" for ...;

(Would prevent the ASI hazard)

import json from "./foo.json" using ...;

8 of 13

Generalized constant form

import a from "b" as { keya: "1", keyb: [2, 3], keyc: 3 };

  • Constant literals, object and array of constant literals
  • Constant form specified by TC39
  • Interpretation up to hosts, just like module specifiers
  • Unclear whether to support in this proposal or a follow-on

9 of 13

Why we're proposing in-band

Either approach could be seen as desirable

Analysis of various environments show pros and cons

Inline has lower bar for adoption

Out of band will require new types of tooling in order to support dependencies

TC39's choice of inline could help coordinate ecosystem adoption

(Out of band is out of scope for TC39; we wouldn't be here if we preferred it)

10 of 13

How much should we specify?

Current draft: module attributes interpreted by the host

Various module types under development in standards, with involvement from TC39 delegates. Some make more sense across environments (JSON, Wasm), others less.

We're open to defining some shared module types, like JSON modules, in ECMA-262.

11 of 13

Implementations

Babel parser WIP, awaiting specification stability:

https://github.com/babel/babel/pull/10962

webpack loader for JSON modules based on module attributes:

https://github.com/xtuc/module-attributes

12 of 13

Spec outline

https://tc39.es/proposal-module-attributes

13 of 13

Questions?