Modules: Curly Free

Kevin Smith zenparsing at gmail.com
Tue Apr 16 12:34:13 PDT 2013


>
> Not only that, but there's also the problem of interoperability with
> existing code (AMD, NPM, etc) that uses the "single dynamic export" idiom.
>

There is that.  We've floated some different ideas in the past for dealing
with this but Andreas dislikes them all.  :)  Here's another option that we
should at least throw on the table:

Not support interoperability.  Load legacy modules with legacy methods and
ES modules with ES syntax.

NPM modules which are upgraded to ES modules can still maintain backward
compatibility with `require` by continuing to set `module.exports = expr`.

An upside to this solution would be that actively maintained NPM modules
would be pressured by users to migrate up to ES modules, thereby moving the
codebase at large away from legacy module systems.

A downside to this solution would be the "pitchfork" risk.

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130416/25388b21/attachment.html>


More information about the es-discuss mailing list