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 <therealbenwi...@gmail.com> 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: > https://github.com/benwiley4000/wildcard-export-override-example > > Ben > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
