

Show HN: Esperanto – Convert ES6 modules to AMD, CommonJS - rich_harris
http://www.rich-harris.co.uk/esperanto/

======
avolcano
One of the reasons this is so relatively simple is that it doesn't appear to
handle cycles like es6-module-transpiler does.

See the test case here:

[https://github.com/thomasboyt/es6-cycles-
comparison](https://github.com/thomasboyt/es6-cycles-comparison)

The es6-module-transpiler output functions correctly, while the Esperanto
output does not. This means that while Esperanto can translate the syntax of
ES6 modules for you, it doesn't currently match semantics like es6-module-
transpiler does.

~~~
rich_harris
Interesting, thanks for the test case - I believe I can add support for cycles
with the current approach (though I'd put it behind an option, since get
default() excludes older browsers), will work on it.

This was a weekend project, using the examples from
[http://jsmodules.io/](http://jsmodules.io/) as a starting point. Not finished
yet :-)

~~~
avolcano
No problem, just wanted to point out one of the reasons for the transpiler's
relative verbosity :)

There's lots of other good test cases here that should be adaptable:
[https://github.com/esnext/es6-module-
transpiler/tree/master/...](https://github.com/esnext/es6-module-
transpiler/tree/master/test/examples)

~~~
rich_harris
That's very useful, thank you.

------
rerooting
I've been using the repo below with ember which has been really powerful.
There are grunt, gulp and broccoli plugins, too. It'd built into ember-cli
where we are spoiled by the best js MVC tooling system I've ever used. Use
ESNext syntax with Sublime Text and you are good to go!

[https://github.com/esnext/es6-module-
transpiler](https://github.com/esnext/es6-module-transpiler)

~~~
rich_harris
I'm very grateful to the authors of es6-module-transpiler - we've been using
it in production for some time. But I ended up writing Esperanto anyway
because the recent versions of es6-module-transpiler don't do one-to-one
input-output mapping; instead it tries to resolve your entire dependency
graph. We found that meant you can't use it with e.g. AMD modules in a
separate vendor/ folder.

I've written some more about why to use Esperanto instead of the alternatives
here: [https://github.com/Rich-Harris/esperanto#why-not-use-
existin...](https://github.com/Rich-Harris/esperanto#why-not-use-existing-
module-transpilers)

Esperanto will have plugins for those build tools soon! Oh, and I second your
recommendation for the Sublime JavaScriptNext package.

------
jbish
Nice work. Just going through the example conversions is helpful in
understanding some of the syntax differences.

I'm a bit confused by the Named imports example though. What is the signifance
of the __imports_0 variable in both the AMD and CommonJS conversions?

~~~
rich_harris
Thanks. In the Named imports example, the `import { later } from 'asap'` line
means 'load the contents of 'asap.js', and make its 'later' export available
to this module as 'later'. In 2014 terms, that means 'assume that asap.js
exports an object with a 'later' property, and map that to the 'later'
variable' \- so '__imports_0' just refers to the object that asap.js exports.

I plan to make this a bit friendlier in a future version of Esperanto:
[https://github.com/Rich-Harris/esperanto/issues/3](https://github.com/Rich-
Harris/esperanto/issues/3)

------
nailer
Neat. Maintain things in a single format, port to other formats as needed.
I've used UMD before but that's a lot of ugly boilerplate - something external
is a much cleaner solution.

