ES6 and legacy module compatibility

# Isiah Meadows (11 years ago)

I know that this subject has been beaten and tortured to the point it would be a bloody corpse if a living being, but I don't recall one specific aspect being addressed so far:

How will legacy modules (CommonJS, AMD, browser "window" variable, etc.) be supported in ES6 imports?

Would it be a simple copy of the environment, implementation defined, or something else?

I know that this subject has been beaten and tortured to the point it would
be a bloody corpse if a living being, but I don't recall one specific
aspect being addressed so far:

How will legacy modules (CommonJS, AMD, browser "window" variable, etc.) be
supported in ES6 imports?

Would it be a simple copy of the environment, implementation defined, or
something else?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140703/7aa1b848/attachment.html>

# Brian Di Palma (11 years ago)

SystemJS seems the best approach at the moment.

systemjs/systemjs

The ES6 module loader shouldn't have any built in knowledge of these other specs. It should be up to us to use loaders that are patched to understand these legacy module systems. Or we could compile these modules to ES6 modules and consume them with the default loader.

Legacy module system features like "object-as-module" could also be supported by these custom interoperability loaders. Most likely by having them export a well known identifier (the ones suggested were default, exports or _) or a compiler can be configured to add a provided name.

import {default as Emitr} from 'emitr';
import {exports as Emitr} from 'emitr';
import {_ as Emitr} from 'emitr';

Note that this is what SystemJS is already doing with CommonJS modules, using "default". So

import {default as Emitr} from 'emitr';

Works right now.

Or if you control all your legacy codebase you could just compile it to ES6 wholesale.

SystemJS seems the best approach at the moment.

https://github.com/systemjs/systemjs/

The ES6 module loader shouldn't have any built in knowledge of these
other specs.
It should be up to us to use loaders that are patched to understand
these legacy module systems.
Or we could compile these modules to ES6 modules and consume them with
the default loader.

Legacy module system features like "object-as-module" could also be
supported by these custom interoperability loaders.
Most likely by having them export a well known identifier (the ones
suggested were default, exports or _) or a compiler can be configured
to add a provided name.

```
import {default as Emitr} from 'emitr';
import {exports as Emitr} from 'emitr';
import {_ as Emitr} from 'emitr';
```

Note that this is what SystemJS is already doing with CommonJS
modules, using "default". So

```
import {default as Emitr} from 'emitr';
```

Works right now.

Or if you control all your legacy codebase you could just compile it
to ES6 wholesale.

B.