@Jordan: yes that also works, but for a less trivial example that is annoying to maintain. I prefer to narrow in sources of truth where possible. But yes that would satisfy the app user requirements, just make the library dev's job more annoying.
@Guy: no unintentional sorry. The intent was to show an actual override. :) Le ven. 14 févr. 2020 04 h 17, Guy Bedford <[email protected]> a écrit : > 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
