Double wildcard "re-exports"... off-limits forever?

Ben Wiley therealbenwiley at
Fri Feb 14 14:18:49 UTC 2020

@Jordan: yes that also works, but for a less trivial example that is
annoying to maintain. I prefer to narrow in sources of truth where
possible. But yes that would satisfy the app user requirements, just make
the library dev's job more annoying.

@Guy: no unintentional sorry. The intent was to show an actual override. :)

Le ven. 14 févr. 2020 04 h 17, Guy Bedford <guybedford at> a écrit :

> Did you mean to have both examples use ‘export const a = 1’?
> This ambiguous export case is supposed to be an explicit error from the
> spec. If the export is being stripped and not throwing an error sounds like
> a possible browser bug.
> On Fri, Feb 14, 2020 at 09:09 Jordan Harband <ljharb at> wrote:
>> Wouldn't the solution be, don't use `import * as`, but instead,
>> explicitly import and re-export what you want?
>> On Thu, Feb 13, 2020 at 8:02 PM Ben Wiley <therealbenwiley at>
>> wrote:
>>> Apologies if this has already been talked about at length at some point.
>>> I was unable to find much in the way of relevant discussions.
>>> I found a compelling use case for something which seems to be off-limits
>>> in the JavaScript language, that is wildcard re-exporting where the same
>>> export name appears in multiple of the export-forwarded imports.
>>> e.g.
>>> ```
>>> // a.js
>>> export const a = 1;
>>> // b.js
>>> export const b = 2;
>>> // c.js
>>> export * from './a.js';
>>> export * from './b.js';
>>> ```
>>> The ideal use case would be shipping an "override library" that ships
>>> all the default exports of an upstream library, except it replaces some of
>>> them with its own overrides. The object-oriented folks might think of it
>>> like a derived class. This can of course be accomplished alternatively by
>>> exporting an object which merges all the named exports from each library,
>>> but the major disadvantage I see is that we would no longer have access to
>>> tree-shaking, since that object contains *all* of the exports. For a really
>>> big upstream library, that could make a large difference in kilobytes
>>> shipped to the browser. So preserving the named exports is desirable.
>>> The protections against double-re-exporting vary. In Chrome and Firefox,
>>> there are no runtime errors but the duplicated exports will be stripped and
>>> unavailable. If you try Babel or Typescript, the compiler will throw an
>>> error.
>>> I understand *not* protecting against this could lead to very weird
>>> debugging situations for unwitting users who didn't realize their wanted
>>> import was being overwritten, however I'd love if there were a way to say
>>> "I know what I'm doing, don't stop me." As far as I can immediately tell
>>> nothing about ES imports would prevent the compiler from being able to know
>>> the order of precedence for overridden exports, and the "ambiguity" would
>>> be mainly from the perspective of an unwitting user. I recognize that
>>> import trees may be processed in parallel, however since code execution is
>>> delayed until the import tree is complete I would think we could resolve
>>> any ambiguities by that time. However it's possible I missed something -
>>> maybe there's a case related to circular imports which ruins this?
>>> Anyway, I wrote up some more detailed thoughts on this problem, and some
>>> demo code, here:
>>> Ben
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list