Double wildcard "re-exports"... off-limits forever?

Augusto Moura augusto.borgesm at
Fri Feb 14 17:47:45 UTC 2020

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:
// 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
export { ApiError as ApiBError, * } from './api-b.js'; // exporting Bar and

// 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 <therealbenwiley at>

> 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:
> Ben
> _______________________________________________
> es-discuss mailing list
> es-discuss at


Augusto Borges de Moura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list