Thanks for Exploring ES6.
I've been investigating ES6 and CommonJS modules support for cyclic dependencies as a part of an effort to translate Java to ES6 via AST transformation (1).
A supported case in Java is cyclic dependencies in class hierarchies. An example in JTS (2), a well known Java library for Geometry, is that the base Geometry class imports subclasses of itself. If not refactored, this kind of relationship will give errors like this from Babel at runtime:
TypeError: Super expression must either be null or a function, not undefined
at Object.babelHelpers.inherits
I'm pretty sure that it's an intentionally unsupported case in Babel at the moment but I'm still not entirely sure it has to be (in post ES5 engines?), even if it can perhaps be considered bad design/practice.
In any case it's a bit sad for me since my effort to translate Java to ES6 otherwise seems to work pretty well. I actually made a manual port of JTS (3) to JavaScript some years ago, but it is getting old and I have no desire of manually updating it. I actually do not know why the manual port works, considering the cyclic dependencies. Perhaps it's because I've manually forced a dependency order that just happens to work out.
My point is, that it might be worthwhile to mention this limitation in Exploring ES6, in the section on cyclic dependencies (4). I've spent many fruitless hours trying to understand and get around this limitation. I have not been able to find out what magic is going on in Java compilers/runtimes to make it work there.
Regards
Björn Harrtell