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

Ben Wiley therealbenwiley at gmail.com
Fri Feb 14 04:01:51 UTC 2020


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:
https://github.com/benwiley4000/wildcard-export-override-example

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200213/84989c9a/attachment.html>


More information about the es-discuss mailing list