Do Anonymous Exports Solve the Backwards Compatibility Problem?

Sam Tobin-Hochstadt samth at ccs.neu.edu
Thu Dec 20 05:17:38 PST 2012


On Thu, Dec 20, 2012 at 5:54 AM, Andreas Rossberg <rossberg at google.com> wrote:
> On 20 December 2012 05:24, Brendan Eich <brendan at mozilla.com> wrote:
>>
>> Domenic Denicola wrote:
>>>>
>>>> IMO this is undesirable. In such a situation, modules can no longer be
>>>> abstraction boundaries. Instead you must peek inside each module and see
>>>> which form it exported itself using.
>>
>>
>> You have to know what a module exports, period. That *is* the abstraction
>> boundary, the edge you must name or otherwise denote.
>>
>> All Andreas is arguing for is a runtime error when you try to denote an
>> anonymous export but the module does not match.
>
> A static error, actually.

While I sympathize with this desire, there are definite drawbacks,
which is why we haven't done this so far.

We want to support *both* a syntax for 'import a module, and bind a
particular identifier to the single anonymous export' and a syntax for
'import a module, and bind an identifier to the module instance
object'.  We could make these different syntaxes, but then (a) we need
to similar syntaxes, which will confuse people when they use the wrong
one and it doesn't work, and (b) you can't switch the implementation
of a module from 'single export' to 'multiple export' without breaking
clients.

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.

Sam


More information about the es-discuss mailing list