Re: Re: Re-export default?

This proposal would solve my issues: https://github.com/leebyron/ecmascript-more-export-from And alas it seems I was correct that this is not an impossible problem to solve at all.___ es-discus

Re: Re-export default?

Seems like more maintenance given the duplication and your spreading the footprint of something that should be expressed in one line if it really is a simple re-export semantic that is trying to be expressed. > On Feb 19, 2015, at 9:22 AM, Matthew Robb wrote: > > Why not simply > > import a

Re: Re-export default?

It doesn’t seem like an impossible problem since other platforms solve this fine without compromising on static analyzability (e.g. Haskell I imagine). But I must admit I’m completely unfamiliar what particular sticking points in the JavaScript platform particularly rule out the possibility of t

Re: Re-export default?

Jason, the most important feature of ES modules is that they are statically verifiable. Something like `import * from “./foo”` goes against that principle because you cannot know ahead of time what are those specifiers. Essentially, you will have to type those specifiers no matter what :), no su

Re: Re-export default?

Hi Caridy, I think you misunderstood my comment about import * from ‘./foo’ I am aware of import * as foo from ‘./foo’ and that is fine. My former example is the desire to have `foo`’s exports injected as-is into the module’s scope (bar vs foo.bar, etc.). There are times where this

Re: Re-export default?

inline > On Feb 19, 2015, at 7:50 PM, Jason Kuhrt wrote: > > Hey Matthew, > > This is another pattern I could take yup. > > Kevin pointed that if I suck it up and move all my modules toward > named-exports then my problems go away too. The reason I am using default > internally was that I ha

Re: Re-export default?

Hey Matthew, This is another pattern I could take yup. Kevin pointed that if I suck it up and move all my modules toward named-exports then my problems go away too. The reason I am using default internally was that I had modules depending on others which are all uniformly single-function modul

Re: Re-export default?

​Just curious if this meets the use cases being discussed here, @caridy @jason ? ​ On Thu, Feb 19, 2015 at 9:22 AM, Matthew Robb wrote: > import a from "a"; > import b from "b"; > > export { a, b }; > - Matthew Robb ___ es-discuss mailing list es-d

Re: Re-export default?

inline... > On Feb 19, 2015, at 8:18 AM, Jason Kuhrt wrote: > > I hear the verdict but not any substantial rationale; why is it “confusing”?’ what it’s confusing from your initial question (export foo from “foo”) is the `foo`, which looks like a local identifier. > @caridy regarding your exam

Re: Re-export default?

Why not simply import a from "a"; import b from "b"; export { a, b }; On Feb 19, 2015 8:18 AM, "Jason Kuhrt" wrote: > I hear the verdict but not any substantial rationale; why is it > “confusing”?’ > > @caridy regarding your examples for JS2016 wouldn’t this > > export default from “foo”; >

Re: Re-export default?

I hear the verdict but not any substantial rationale; why is it “confusing”?’ @caridy regarding your examples for JS2016 wouldn’t this export default from “foo”; just re-export one module’s default as another module’s default, right? In my use-case, in order to map n-number of default-expor

Re: Re-export default?

Yes, that syntax is incorrect and confusing. There was an overside from our end to provide a way to re-export only the default export from another module, and this is something we plan to revisit for ES7/2016. Probably something like this: `export default from “foo”;` this is just sugar

Re: Re-export default?

> > > > export foo from ‘./foo' > I personally would find such a construct terribly confusing. But then again I find the entire default export business terribly confusing. ; ) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/