Feed back and proposal for modules: allow importing ES5 files

[程劭非]

Thanks, Claus and Alex,

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

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.

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>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120925/ba3bb463/attachment-0001.html>