ES Module Attributes
Status update
Myles Borins, Google
Daniel Ehrenberg, Igalia in partnership with Bloomberg
Sven Sauleau, Babel
Daniel Clark, Microsoft
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:
*Depending on the design
Proposed syntax
import json from "./foo.json" as "json";
Update to dynamic import (part of this proposal)
import("foo.json", "json")
Second argument is the Module type of foo.json
Proposed Web API (Separate Web proposal)
new Worker("foo.wasm", { as: "webassembly" })
Cannot use type as workers already utilize that property.
AsClause may be extended for more constant types
"ASI hazard" case is unlikely (\nas\n)
Other keywords to consider
import json from "./foo.json" for ...;
(Would prevent the ASI hazard)
import json from "./foo.json" using ...;
Generalized constant form
import a from "b" as { keya: "1", keyb: [2, 3], keyc: 3 };
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)
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.
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
Spec outline
https://tc39.es/proposal-module-attributes
Questions?