Do Anonymous Exports Solve the Backwards Compatibility Problem?
khs4473 at gmail.com
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss