Again, I sent only to Axel, but meant for the list, resending... On Thu, Jan 12, 2012 at 1:57 AM, Axel Rauschmayer <[email protected]> wrote: > I think introducing new language constructs for modules is good, because > they are so fundamental. For incrementally migrating old code bases, it > would make a lot of sense to allow ES.next modules to import AMDs and vice > versa.
I don't see ES.next modules being able to natively import AMD modules, particularly if the "compile time binding for 'module'/'exports'/'import' are in play. I'm happy to be wrong though. What I do not like is the "just run this conversion script". I would like today's scripts to be able to easily opt in without having to provide two versions or force conversion work. And being able to shim an ES module API now for trial use on the web today would be useful to shake out the kinks. In particular, there are some choices around module ID resolution that us folks in AMD-land are still shaking out (more below). Although the answer for that could be just "let node and the AMD folks test those areas and feed that back into the syntax-based design". I appreciate this is a hard problem. My main point is that what might look like a simple syntax inside the module have complications outside of it, particularly for code mixing. To be clear I'm not against new syntax at all in the language, it is just that for being able to get handles on code units is pretty fundamental, and being able to use code on the web today as part of graduating into natively supported modules would ease adoption and reduce developer swirl. But the folks working on the module stuff here might already have plans for all of that. I'll be happy to see it laid out at some point. > Furthermore, npm’s ability to install modules locally and to let local > modules shadow global ones is a very smart way out of version hell. It would > be nice to have something similar for ES.next modules, but it’ll be harder > to do for browsers (as opposed to for Node.js and local file access). I expect part of the path resolution logic will not be possible to mandate in an ES spec. Or at least, there will be different rules for things like node vs browsers. For browsers, everything is effectively local, and you get one network lookup path. We're still working through some of these issues on the AMD-implement list, particularly around multiple versions of a module in a project. Node's nested node_modules is not efficient for the web. I think we have worked something out though in the "map" config discussed here: https://groups.google.com/group/amd-implement/browse_thread/thread/c36e284a7f85021a That thread also has some details on what sort of tradeoffs there are for baseUrl + moduleId + '.js' lookup rules vs a "package" system with a "main". James _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
