Show HN: Esperanto – Convert ES6 modules to AMD, CommonJS(rich-harris.co.uk)
rich-harris.co.uk
Show HN: Esperanto – Convert ES6 modules to AMD, CommonJS
http://www.rich-harris.co.uk/esperanto/
4 comments
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/ as a starting point. Not finished yet :-)
This was a weekend project, using the examples from http://jsmodules.io/ as a starting point. Not finished yet :-)
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/...
There's lots of other good test cases here that should be adaptable: https://github.com/esnext/es6-module-transpiler/tree/master/...
That's very useful, thank you.
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
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...
Esperanto will have plugins for those build tools soon! Oh, and I second your recommendation for the Sublime JavaScriptNext package.
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...
Esperanto will have plugins for those build tools soon! Oh, and I second your recommendation for the Sublime JavaScriptNext package.
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?
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?
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
I plan to make this a bit friendlier in a future version of Esperanto: https://github.com/Rich-Harris/esperanto/issues/3
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.
See the test case here:
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.