Harmony modules feedback

James Burke jrburke at gmail.com
Mon Jan 16 21:11:03 PST 2012

Again, I sent only to Axel, but meant for the list, resending...

On Thu, Jan 12, 2012 at 1:57 AM, Axel Rauschmayer <axel at rauschma.de> 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:


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


More information about the es-discuss mailing list