Static Module Resolution

Andreas Rossberg rossberg at google.com
Sun Jul 1 03:51:44 PDT 2012


On 30 June 2012 22:38, John J Barton <johnjbarton at johnjbarton.com> wrote:

> As Dave suggests, my gut feeling is that we don't want
>     // main.js
>     import g from "./legacy.js";
> to mean "legacy.js" can be ES6 or not. It's ES6 or it's an error.
>
> However, let's consider your proposal anyway. Let's read main.js and parse
> it.
>     // main.js
>     import g from "./legacy.js";
> Now we know we need legacy.js, so we fetch it and parse it. Does it form
> an ES6 module? Go with it. No? Ok fallback and execute it
> using compatibility rules. This could include looking for clues that tell
> us this is an AMD or node file. We know this mode is a hack, we only need
> it to be good enough to push modules over the hump.
>

Almost any old JS file (except for one containing 'with' I think) forms a
legal ES6 module body -- it's just not going to export anything.

So as Dave said, you'd probably need an explicit import-side distinction to
differentiate.

/Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120701/da16d2d3/attachment-0001.html>


More information about the es-discuss mailing list