Do Anonymous Exports Solve the Backwards Compatibility Problem?

Kevin Smith khs4473 at
Thu Dec 20 08:22:19 PST 2012

The latter scenario isn't important for the 'module exports a single
> function which is identified with the module' case, but it is
> important for gradual migration to ES6. It's much easier to convert an
> ES5 library that attaches a single value to the global object to a
> single-export module by wrapping it with some boilerplate, or
> configuring a loader hook to do such wrapping, than it is to do a
> fundamental conversion to use ES6 features.  Therefore, I imagine that
> existing libraries will go through a period where they're usable via
> the module system as single-exports modules exporting their current
> object.  Later, we might like to convert these modules more fully, and
> that should be possible without breaking clients.

At first I thought so too.

This is exactly the use case that my OP addresses.  The logic goes like
this:  in order to apply that boilerplate, you have to know whether the
module is ES5 or ES6.  In order to know that, you have to parse it.
 Pre-parsing every single module is not practical for a production system.
 Therefore applying such boilerplate is not practical for a production

No - the solution for Node WRT ES6 modules, in my mind, is to "pull off the
bandaid".  The solution should not be to make compromises on the module
design side.

- Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list