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

Guy Bedford guybedford at
Fri Feb 14 09:17:42 UTC 2020

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