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

Jordan Harband ljharb at
Fri Feb 14 07:09:02 UTC 2020

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list