<div dir="auto">@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.<div dir="auto"><br></div><div dir="auto">@Guy: no unintentional sorry. The intent was to show an actual override. :) </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 14 févr. 2020 04 h 17, Guy Bedford <<a href="mailto:guybedford@gmail.com">guybedford@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div dir="auto">Did you mean to have both examples use ‘export const a = 1’?</div></div><div dir="auto"><br></div><div dir="auto">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.</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 14, 2020 at 09:09 Jordan Harband <<a href="mailto:ljharb@gmail.com" target="_blank" rel="noreferrer">ljharb@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Wouldn't the solution be, don't use `import * as`, but instead, explicitly import and re-export what you want?<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 13, 2020 at 8:02 PM Ben Wiley <<a href="mailto:therealbenwiley@gmail.com" target="_blank" rel="noreferrer">therealbenwiley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>e.g.</div><div>```</div><div>// a.js</div><div>export const a = 1;</div><div><br></div><div>// b.js</div><div>export const b = 2;</div><div><br></div><div>// c.js</div><div>export * from './a.js';</div><div>export * from './b.js';</div><div>```<br><br>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.</div><div><br>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.</div><div><br></div><div>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?<br><br>Anyway, I wrote up some more detailed thoughts on this problem, and some demo code, here: <a href="https://github.com/benwiley4000/wildcard-export-override-example" target="_blank" rel="noreferrer">https://github.com/benwiley4000/wildcard-export-override-example</a><br><br>Ben</div></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank" rel="noreferrer">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank" rel="noreferrer">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div></div>
</blockquote></div>