Feed back and proposal for modules: allow importing ES5 files

[Claus Reinke]

> I've looked at the Loader but it seems to be async?

So far, yes, but previous discussions here led to the conclusion
that making the Loader functionality available for module syntax
imports would be useful and unproblematic. See, for instance,
the final paragraph of

https://mail.mozilla.org/pipermail/es-discuss/2012-July/024184.html

Perhaps that hasn't been worked into the spec yet. I hope it
doesn't get lost.

> I know there are many ways to load multiple files together(iframe,
> XHR, script element and datauri for browser host) but what I'm
> suggesting is to make es6 module more friendly to es5 libraries.

At first, a standard Loader plugin for treating ES5 scripts as modules
sounds useful, instead of everyone writing their own. Especially if a
generic script-as-modules-wrapper requires code analysis to figure
out global assignments.

That, however, is exactly the issue: ES5 scripts are not friendly to
ES6 modularity, as all export information is encoded dynamically -
one cannot figure out the exports without running the code.

So a general ES5-scripts-as-modules seems unlikely, and even
if one wanted to write converters for each currently encoded
module system, one would run into the runtime-vs-static issue,
unless all modules happen to use a static subset of current
module libraries (most module interface code will be static
in intention, if not in expression, but there are no guarantees).

Which is why I was referring to the RequireJS approach of
encoding the expected exports in the wrapper configuration.

Translating that to ES6 should be possible: we'd not even try
to extract the global assignments from the code automatically;
instead we'd tell the module wrapper manually how to extract
the expected exports from whatever the ES5 module code does
to its environment, by appending export declarations to the ES5
code. At least, that is how I understand this approach;-)

Claus

> I mean currently the es6 module grammar is using
>
> export var a;
> var b;
> var c;
>
> But why not export all top-level scope variables and let developers use
> IFFE to hide variables?
>
> var a; // export a automatically
> void function(){
>    var b;
>    var c;
> }();
>
> This will make libraries like old versions of jQuery work with es6 module
> without any code change. These libraries might be on CDN and changing their
> code will be a big cost in some scenarios.
>
>
> 2012/9/24 Alex Russell <alex at dojotoolkit.org>
>
>> I think module loaders would, indeed help, although as you point out,
>> you're gonna need some sort of transformation step and we don't provide an
>> AST to work against. You might need something like Traceur's front-end or
>> esprima to get started on a reliable transform pass. But yeah, doable.
>>
>>
>> On Mon, Sep 24, 2012 at 4:08 PM, Claus Reinke <claus.reinke at talk21.com>wrote:
>>
>>>
>>>  Right. What I'm suggesting isn't that you'll be able to prevent the
>>>> global
>>>> from being augmented, rather that if your goal is to take an *already
>>>> well
>>>> behaved* library and wrap it with modules, that's possible.
>>>>
>>>
>>> Aren't Module Loader Translation hooks meant to help with this?
>>>
>>> http://wiki.ecmascript.org/**doku.php?id=harmony:module_**
>>> loaders#translation_semantics<http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders#translation_semantics>
>>>
>>> Naïve idea: fetch the code, then add exports before evaluating the
>>> code as a local module scope.
>>>
>>> Though this would require parameterizing the Loader with some
>>> configuration data (export $ from jquery, export {f,g,x} from
>>> anotherES5utils, ..). Which seems to call for interaction between
>>> fetch and translate hooks, and possibly even between import
>>> declarations and loader hooks (how does the loader hook get
>>> to know which exports to add to an ES5 script, for a given import
>>> declaration?).
>>>
>>> RequireJS has some experience with wrapping non-modules
>>> via configuration options.
>>>
>>> https://github.com/jrburke/**requirejs/wiki/Upgrading-to-**
>>> RequireJS-2.0#wiki-shim<https://github.com/jrburke/requirejs/wiki/Upgrading-to-RequireJS-2.0#wiki-shim>
>>>
>>> Without a prototype implementation of modules as an executable
>>> spec, it will be difficult to find such edge cases and check how well
>>> they are covered in the existing semi-formal spec.
>>>
>>> Claus
>>>
>>>
>>>
>>> ______________________________**_________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>>
>>
>>
>