Modules spec procedure suggestion (Re: Jan 31 TC39 Meeting Notes)

[James Burke]

On Thu, Feb 7, 2013 at 1:00 PM, Claus Reinke <claus.reinke at talk21.com> wrote:
> There are some existing ES.next modules shims/transpilers that
> could be used as a starting point.

Here is an experiment I did with a JS module syntax that allowed for a
static compile time hooks for things like macros, but still allowed JS
that needed to exist both in pre-ES.next and ES.next to opt into
modules (think base libraries like jQuery, underscore, backbone).

https://github.com/jrburke/modus

It has some tests, and the modus.js file runs in ES5 browsers.

Since the modules desugar to runtime APIs after the compile time pass
for macros, it means not getting the lower level variable bindings
that the ES module format is targeting. This means it has similar
cycle dependency support as AMD -- it can be done, but may not be as
nice as ES module variable binding, and has some restrictions.

The API and syntax was just provisional, just something chosen to wire
things together, and it is not a fully fleshed out system. Also, it
was not done to advocate macros in particular. Macros were used to
demonstrate how a static, "compile time" feature could be supported in
a system that desugared to runtime API calls, and it helped that
sweetjs was available for that heavier lifting.

It may be useful for others to look at as a way to prototype any
official ES spec approach, even if it does not give full fidelity. In
particular, the use of the sweetjs reader to do a first pass transform
of the module syntax.

James