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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
