Re: Double wildcard "re-exports"... off-limits forever?
Augusto,
I think the rest import/export could be an interesting idea although it
doesn't quite solve my case since I would like to keep the original names
and treat one API as an override of the other (in your case it seems you're
trying to combine all exports from multiple libraries by changing names in
some cases). The rest export would also still require explicitly naming the
duplicate re-exports, which means redundant export declarations.
I did consider something very similar (like rest imports) while I was
trying to arrive at a solution though. It's a cool idea for sure!
Something that could avoid the dangerous situation that necessitated the
duplicate re-export rule in the first place, would be to have some kind of
"joint import/export" syntax designed for this use case, where multiple
import sources are accepted.
e.g.
```js
// api-base.js
export { Foo, ApiError };
// api-derived.js
export { Bar, ApiError };
// index.js
export * from './api-base.js', './api-derived.js';
// or...
import * as api from './api-base.js', './api-derived.js';
```
This way you're explicitly stating your intent for exports from the first
source to be override-able by those from the second source. Semantically,
at a high level you can think of this as having behavior similar to
Object.assign or an object rest spread, where first a set of exports is
formed from the first source, then the second set of exports is grafted on
top, possibly overriding some values, then a potential third source, and so
on.
Various implementations could be considered, including reading the exports
from right-to-left to avoid registering the same export name twice
(although I'd guess the http requests wouldn't be fired until all export
paths are determined anyway, so might not make a meaningful difference).
Ben
On Fri, Feb 14, 2020 at 12:47 PM Augusto Moura
wrote:
> 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
> 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 kiloby
Re: Double wildcard "re-exports"... off-limits forever?
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
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
Re: Double wildcard "re-exports"... off-limits forever?
@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 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 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 >> 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 >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Double wildcard "re-exports"... off-limits forever?
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 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 > 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 >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Double wildcard "re-exports"... off-limits forever?
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 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 > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Double wildcard "re-exports"... off-limits forever?
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
Wildcard
It wouldn’t be breaking if it was the only identifier that one was allowed to use multiple time, right? But I do like the idea of the dot. Would be nice for destructuring arrays, too: let [., ., third] = myArray; On Dec 30, 2012, at 13:01 , Andreas Rossberg rossb...@google.com wrote: On 30 December 2012 12:50, Axel Rauschmayer a...@rauschma.de wrote: It would actually be nice to have that as a feature: If the variable name is `_` then it can be used multiple times. It’s a nice, self-descriptive way of saying that you don’t care about a parameter value. That underscore wildcard is the exact syntax used in functional languages, and very useful, I agree. In JS, that syntax would be a breaking change, unfortunately. But we could use something else (e.g. I proposed '.' in the past). /Andreas -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Wildcard
I think that nothing wins over dot or underscore for marking unused
positions, for one simple reason: it is implemented for years in every engines
in constructs like:
var myArray = [ , , third]
So it seems more natural to me to have something like: function( , , z) { /*
... */ }
But anyway, if one day I'll need more than one unused parameter, I would first
ask me seriously if it would not be better to refactor my function's signature
with something like:
function f({z: z}) { /* ... */ }
f({x: first, y: second, z: third})
instead of:
function f( , , z) { /* ... */ }
f(first, second, third)
Claude
Le 30 déc. 2012 à 13:06, Axel Rauschmayer a...@rauschma.de a écrit :
It wouldn’t be breaking if it was the only identifier that one was allowed to
use multiple time, right?
But I do like the idea of the dot. Would be nice for destructuring arrays,
too:
let [., ., third] = myArray;
On Dec 30, 2012, at 13:01 , Andreas Rossberg rossb...@google.com wrote:
On 30 December 2012 12:50, Axel Rauschmayer a...@rauschma.de wrote:
It would actually be nice to have that as a feature: If the variable name is
`_` then it can be used multiple times. It’s a nice, self-descriptive way of
saying that you don’t care about a parameter value.
That underscore wildcard is the exact syntax used in functional
languages, and very useful, I agree. In JS, that syntax would be a
breaking change, unfortunately. But we could use something else (e.g.
I proposed '.' in the past).
/Andreas
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
