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
