If I understand it correctly, I had a similar problem with generated apis from OpenApi, two apis have a error definition with the name ApiError, i want to reexport all classes (a lot of model definitions) from both apis. The problem is that using `export * from 'api-a'; export * from 'api-b';` raises a error that ApiError is a duplicated name. So I have 2 options, or I reexport all definitions from the apis explicitly (hundreds of `export { Foo } from 'api-b'`) just to rename the ApiError to ApiAError at then end or I don't rexport then together at all (splitting the reexports in 2 files and having the dev to import the necessary models from the different files).
If we could have a rest-operator like construct for imports the problem would be solved, something like: ```js // api-a.js export { Foo, ApiError }; // api-b.js export { Bar, ApiError }; // apis.js export { ApiError as ApiAError, * } from './api-a.js'; // exporting Foo and ApiAError export { ApiError as ApiBError, * } from './api-b.js'; // exporting Bar and ApiBError // other ideas for syntax export { ApiError as ApiAError }, * from './api-a.js'; // similiar to default and named imports export { ApiError as ApiAError, ... } from './api-a.js'; // similar to spread syntax export { ApiError as ApiAError, ...* } from './api-a.js'; // mix from spread syntax and wild card imports // this last is one is the one I like the most, because both wildcards and spread are already familiar in the language, and it reads like "import the rest and rexport as it is" ``` Em sex., 14 de fev. de 2020 às 01:02, Ben Wiley <therealbenwi...@gmail.com> escreveu: > 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 > -- Atenciosamente, Augusto Borges de Moura
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss