Static Module Resolution

John J Barton johnjbarton at johnjbarton.com
Sat Jun 30 13:38:27 PDT 2012


On Sat, Jun 30, 2012 at 12:03 PM, Kevin Smith <khs4473 at gmail.com> wrote:

> Just define the order of execution between ES6 and pre-ES6 to run
>> legacy.js first.
>>
>
> You'd have to detect (before execution) whether a script was "ES6" or not,
> which is not practical, AFAICT.
>

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.


>
> But even if you could, then simply upgrading "legacy.js" to use ES6
> modules would change the order of execution, which could cause observable
> differences of behavior in the program.
>

yes, modules change the order of execution.  I doubt we can hope for
"simply upgrading".  However, I don't think it necessarily follows that
interoperation is impossible and that is much more important.

jjb

- Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120630/3afa2d9d/attachment.html>


More information about the es-discuss mailing list