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 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 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
