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 <[email protected]>
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 <[email protected]>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
[email protected]
https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
