Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Why it's hard to map ES6 modules 1:1 into CommonJS or AMD

Why it's hard to map ES6 modules 1:1 into CommonJS or AMD

Originally from an email, gisted here for posterity:

I was able to remember the example where "naive" 1:1 module transpilation fails:

// ------- foo.js --------
var a = 5;

function update() {
  a = 10;

export { a, update };
// -------- bar.js -------
import { a, update } from './foo';
export { a, update };

// Equivalent to re-export syntax
//   export { a, update } from './foo';
// but es6-module-transpiler doesn't support this syntax yet (#188)
// --------- baz.js -------
import { a, update } from './bar';


// This should output 10, not 5.

es6-module-transpiler handles this correctly by binding the a identifier all the way through, as required by the ES6 spec.

I had conversations with several people about this in the past, and we couldn't find a viable way of doing 1:1 transpilation that covered this ^ case as well as circular imports. I haven't kept up since, but presumably that's what motivated Brian (@eventualbuddha) to rewrite the es6-module-transpiler in a way that emits a single output file for a set of input files (n:1).

Update: Esperanto handles this correctly as well, with either its "bundle" mode, or using defineProperty in AMD/CJS mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment