Do Anonymous Exports Solve the Backwards Compatibility Problem?
samth at ccs.neu.edu
Thu Dec 20 08:30:18 PST 2012
On Thu, Dec 20, 2012 at 11:22 AM, Kevin Smith <khs4473 at gmail.com> wrote:
>> 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
I don't think this is right. Certainly if you want to take arbitrary
code, which might be an ES6 module or an ES5 library, and wrap it in a
module only if needed, then parsing is required. However:
(a) Parsing is fine in a production *build* system.
(b) Not every use case has to handle both input cases. For example,
a tool to convert an ES5 library to an ES6 module, which might be run
as part of a module loader hook, should just assume that its input is
written in ES5. The same goes for ahead-of-time conversion tools.
> 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.
Whether to have anonymous exports is not about making a compromise in
the design for compatibility (modulo the syntax issue discussed
above). This is an idiom that's widely used in JS today, and we're
not trying to tell people what style they should use in the future.
More information about the es-discuss