Re: Quantifying Default Exports
Hi Calvin,
On 21 juil. 2014, at 17:16, Calvin Metcalf
mailto:calvin.metc...@gmail.com>> wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
Just to be exact this wouldn't be exactly a "CommonJS" module
http://wiki.commonjs.org/wiki/Modules
module.exports isn't part of any of the 1.0, 1.1, or 1.1.1 versions of the
CommonJS modules specification
CommonJS doesn't support neither to replace the original exports object
reference by another, so:
```js
exports = function (){}
```
First implemented in node.js, then in few SSJS implementations to better
support node modules
it never was accepted as part of the standard, because considered as too error
prone
https://groups.google.com/forum/#!searchin/commonjs/cyclic/commonjs/DECN5h4Lfms/-BrIu7TpKQkJ
and is still not supported by some other CommonJS implementations
[cid:81032e.png@a90d966c.47bea091]
Alexandre Morgaut
Wakanda Community Manager
Email : alexandre.morg...@4d.com
Web : www.4D.com
4D SAS
60, rue d'Alsace
92110 Clichy - France
Standard : +33 1 40 87 92 00
[cid:89448b.png@dd969963.47bf9b71]
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
This is why I have previously posted asking for a function to determine if
a given object is a module object.
Given such a function, *Reflect.isModule* say, we can convert our code to
AMD or CommonJS like the following:
import p from 'module';
Converts to CommonJS:
var module = require('module');
if (!Reflect.isModule(module)) {
module = { default: module };
}
var p = module['default'];
Now whether the module is an ES6 module or another CommonJS module, we get
what we expect.
On 22 July 2014 20:43, Kevin Smith wrote:
>
>> We then conditionally add this wrapper based on detecting if the import
>> is an ES6 module. This is the same method we have for AMD compilations at
>> the moment, which seems to have been working well.
>>
>
> Just a side note, but for performance reasons in a real runtime system you
> can't pre-determine whether the target is an ES6 module or not - that would
> imply double-parsing and would necessarily be heuristic and incomplete.
>
> In the end, either the import side or some preconfigured application state
> will have to explicitly specify which targets are ES6 and which are not.
>
> I've worked though most of these issues already in es6now, which provides
> a complete picture of a backward compatible ES6 module system running on
> Node.
>
> https://github.com/zenparsing/es6now/blob/master/docs/modules.md
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
> > > We then conditionally add this wrapper based on detecting if the import is > an ES6 module. This is the same method we have for AMD compilations at the > moment, which seems to have been working well. > Just a side note, but for performance reasons in a real runtime system you can't pre-determine whether the target is an ES6 module or not - that would imply double-parsing and would necessarily be heuristic and incomplete. In the end, either the import side or some preconfigured application state will have to explicitly specify which targets are ES6 and which are not. I've worked though most of these issues already in es6now, which provides a complete picture of a backward compatible ES6 module system running on Node. https://github.com/zenparsing/es6now/blob/master/docs/modules.md ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
On 22 Jul 2014 00:30, "Calvin Metcalf" wrote: > > Wasn't the original issue single exports and their demonstrated utility in node and AMD? Default can be used with named exports, and therefore does not indicate that a module is single export. And you can make a single export module by exporting a single named export. Therefore there is no correlation between default and single exporting modules. The default import is a useful syntactic sugar, but the default export does not map well with it, especially because rather than saving keystrokes it is (potentially) longer to use than a named export. Marius Gundersen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
What utility is that exactly? They are easier to import in terms of typing?
I would hope that with ES6 modules all a programmer would have to
write is the name of the import and the IDE would auto insert the
import statement.
The sort of IDE support you would see for Java or C#, of course that
will only work with named exports.
If everything is default then the IDE can't help that much when it
comes to auto complete and inserts.
I think that issue has already been addressed by people pointing out
that modules were written in the default style due to named exports
being ugly in CJS.
On Mon, Jul 21, 2014 at 11:30 PM, Calvin Metcalf
wrote:
> Wasn't the original issue single exports and their demonstrated utility in
> node and AMD?
>
> On Jul 21, 2014 5:49 PM, "John Barton" wrote:
>>
>> There are two issues here:
>> 1) Is 'default' essential?
>> 2) Should the spec. explicitly define commonjs loading?
>>
>> Brian is claiming 1) no and 2) no. More important for me: does 2) require
>> 1). Evidently not.
>>
>> jjb
>>
>>
>> On Mon, Jul 21, 2014 at 1:34 PM, Brian Di Palma wrote:
>>>
>>> It doesn't seem an issue that requires the ES6 module spec to have
>>> something like default imports though.
>>>
>>> The compiler could output
>>>
>>> `
>>> newModule({
>>> default: require('minimist')
>>> })
>>> `
>>>
>>> and importers could do
>>>
>>> `import {default as minimist} from 'minimist';`
>>>
>>> Or you could have
>>>
>>> `
>>> newModule({
>>> minimist: require('minimist');
>>> })
>>> `
>>>
>>> and
>>>
>>> `import {minimist} from 'minimist';`
>>>
>>> depending on how the compiler is configured/written.
>>>
>>> This is implementation detail of compilers and loaders of legacy
>>> systems as opposed to spec concerns.
>>>
>>> On Mon, Jul 21, 2014 at 6:50 PM, Guy Bedford
>>> wrote:
>>> > Yes this is a bug that can be fixed at the compiler level. As you say
>>> > we can
>>> > generate a wrapper when loading a non-ES6 module in ES6:
>>> >
>>> > newModule({
>>> > default: require('minimist')
>>> > })
>>> >
>>> > We then conditionally add this wrapper based on detecting if the import
>>> > is
>>> > an ES6 module. This is the same method we have for AMD compilations at
>>> > the
>>> > moment, which seems to have been working well.
>>> >
>>> >
>>> > On 21 July 2014 10:17, John Barton wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford
>>> >> wrote:
>>> >>>
>>> >>> In Brian's case we actually need default exports. This is because the
>>> >>> dynamic loader can't pick up the code he has written right now in
>>> >>> ES6.
>>> >>>
>>> >>> This is how he is loading a NodeJS module in ES6:
>>> >>>
>>> >>> module minimist from 'minimist';
>>> >>>
>>> >>> In ES6 this means "give me the Module object with getters to the
>>> >>> exports".
>>> >>>
>>> >>> But unfortunately in Traceur this is compiling into:
>>> >>>
>>> >>> var minimist = require('minimist');
>>> >>>
>>> >>> As a result the `module` syntax can possibly return him a 'function'
>>> >>> or
>>> >>> other non-Module object.
>>> >>
>>> >>
>>> >> You seem to be saying "The traceur implementation of 'module' fails in
>>> >> this case". It seems to me that Traceur could generate code which
>>> >> would
>>> >> wrap functions in Module objects. That is, this is not a fundamental
>>> >> limit,
>>> >> just an unreported bug.
>>> >>
>>> >>>
>>> >>> Thus we have broken the ability to parse his code in the ES6 dynamic
>>> >>> loader, as it is not capable of returning a non-Module object for a
>>> >>> module
>>> >>> import, which is pretty critical.
>>> >>>
>>> >>> Thus default export properties are critical to enabling this support
>>> >>> path.
>>> >>
>>> >>
>>> >> I believe that Caridy's point is: "fine, use dynamic linking".
>>> >>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 21 July 2014 09:51, Caridy Patino wrote:
>>>
>>> Interoperability should not be a decisive factor here, we have
>>> fallen
>>> into that trap before, the conclusion was to let Loader to handle
>>> those
>>> cases rather than trying to drive it from the perspective of the
>>> module
>>> syntax. Let's focus on what is best and what makes sense for the ES
>>> Modules,
>>> and keep the dynamic module systems out of the picture since we know
>>> we have
>>> a lot of flexibility with the loader to deal with those dynamic
>>> modules.
>>>
>>> /caridy
>>>
>>>
>>> On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma
>>> wrote:
>>> >
>>> > Yep, that makes sense. Highly unlikely but still possible and could
>>> > cause issues.
>>> > No doubt you could complicate your compiler to deal with these edge
>>> > cases but why force that?
>>> >
>>> > Yet more problems with default imports/exports. This feature
>>> > doesn't
>>> > seem worth its cost.
>>> >
>>> >
>>> > On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
>>> > wrote:
>>> > > (woops
Re: Re: Quantifying Default Exports
Wasn't the original issue single exports and their demonstrated utility in
node and AMD?
On Jul 21, 2014 5:49 PM, "John Barton" wrote:
> There are two issues here:
> 1) Is 'default' essential?
> 2) Should the spec. explicitly define commonjs loading?
>
> Brian is claiming 1) no and 2) no. More important for me: does 2) require
> 1). Evidently not.
>
> jjb
>
>
> On Mon, Jul 21, 2014 at 1:34 PM, Brian Di Palma wrote:
>
>> It doesn't seem an issue that requires the ES6 module spec to have
>> something like default imports though.
>>
>> The compiler could output
>>
>> `
>> newModule({
>> default: require('minimist')
>> })
>> `
>>
>> and importers could do
>>
>> `import {default as minimist} from 'minimist';`
>>
>> Or you could have
>>
>> `
>> newModule({
>> minimist: require('minimist');
>> })
>> `
>>
>> and
>>
>> `import {minimist} from 'minimist';`
>>
>> depending on how the compiler is configured/written.
>>
>> This is implementation detail of compilers and loaders of legacy
>> systems as opposed to spec concerns.
>>
>> On Mon, Jul 21, 2014 at 6:50 PM, Guy Bedford
>> wrote:
>> > Yes this is a bug that can be fixed at the compiler level. As you say
>> we can
>> > generate a wrapper when loading a non-ES6 module in ES6:
>> >
>> > newModule({
>> > default: require('minimist')
>> > })
>> >
>> > We then conditionally add this wrapper based on detecting if the import
>> is
>> > an ES6 module. This is the same method we have for AMD compilations at
>> the
>> > moment, which seems to have been working well.
>> >
>> >
>> > On 21 July 2014 10:17, John Barton wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford
>> >> wrote:
>> >>>
>> >>> In Brian's case we actually need default exports. This is because the
>> >>> dynamic loader can't pick up the code he has written right now in ES6.
>> >>>
>> >>> This is how he is loading a NodeJS module in ES6:
>> >>>
>> >>> module minimist from 'minimist';
>> >>>
>> >>> In ES6 this means "give me the Module object with getters to the
>> >>> exports".
>> >>>
>> >>> But unfortunately in Traceur this is compiling into:
>> >>>
>> >>> var minimist = require('minimist');
>> >>>
>> >>> As a result the `module` syntax can possibly return him a 'function'
>> or
>> >>> other non-Module object.
>> >>
>> >>
>> >> You seem to be saying "The traceur implementation of 'module' fails in
>> >> this case". It seems to me that Traceur could generate code which
>> would
>> >> wrap functions in Module objects. That is, this is not a fundamental
>> limit,
>> >> just an unreported bug.
>> >>
>> >>>
>> >>> Thus we have broken the ability to parse his code in the ES6 dynamic
>> >>> loader, as it is not capable of returning a non-Module object for a
>> module
>> >>> import, which is pretty critical.
>> >>>
>> >>> Thus default export properties are critical to enabling this support
>> >>> path.
>> >>
>> >>
>> >> I believe that Caridy's point is: "fine, use dynamic linking".
>> >>
>> >>>
>> >>>
>> >>>
>> >>> On 21 July 2014 09:51, Caridy Patino wrote:
>>
>> Interoperability should not be a decisive factor here, we have fallen
>> into that trap before, the conclusion was to let Loader to handle
>> those
>> cases rather than trying to drive it from the perspective of the
>> module
>> syntax. Let's focus on what is best and what makes sense for the ES
>> Modules,
>> and keep the dynamic module systems out of the picture since we know
>> we have
>> a lot of flexibility with the loader to deal with those dynamic
>> modules.
>>
>> /caridy
>>
>>
>> On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma
>> wrote:
>> >
>> > Yep, that makes sense. Highly unlikely but still possible and could
>> > cause issues.
>> > No doubt you could complicate your compiler to deal with these edge
>> > cases but why force that?
>> >
>> > Yet more problems with default imports/exports. This feature doesn't
>> > seem worth its cost.
>> >
>> >
>> > On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
>> > wrote:
>> > > (woops hit reply instead of reply all)
>> > >
>> > > Because the `function mainThing(){}` might already have a method
>> > > named
>> > > helper or, more likely, the named export is something like call or
>> > > bind.
>> > >
>> > >
>> > >
>> > >
>> > > On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma <
>> off...@gmail.com>
>> > > wrote:
>> > >>
>> > >> On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
>> > >> wrote:
>> > >> > I have a CommonJS module which exports a single function
>> > >> > ```js
>> > >> > //cj.js
>> > >> > module.exports = function (){}
>> > >> > ```
>> > >> >
>> > >> > If I was to transform it into an ES6 module the best way to do
>> so
>> > >> > currently
>> > >> > it so use a default export
>> > >> >
>> > >> > ```js
>> > >> > //cj2es6.js
>> >
Re: Re: Quantifying Default Exports
>From my understanding there was no spec work done to support bundling.
The reasoning I heard was due to HTTP/2 making this obsolete.
I agree with that and think that's a sensible decision, the community
have come up with their own shared solution which seems to work.
At least that's my understanding of the System.register work.
Could the same approach not be taken for compatability with legacy
module systems?
If traceur and the ES6ML polyfills decide that `default` or `exports`
is the export name they will provide `module.exports` with I will use
that when interfacing with legacy code until it's upgraded.
One day in the future this will no longer be a concern, just like
bundling, so specing it seems to give it undue permanence.
On Mon, Jul 21, 2014 at 10:48 PM, John Barton wrote:
> There are two issues here:
> 1) Is 'default' essential?
> 2) Should the spec. explicitly define commonjs loading?
>
> Brian is claiming 1) no and 2) no. More important for me: does 2) require
> 1). Evidently not.
>
> jjb
>
>
> On Mon, Jul 21, 2014 at 1:34 PM, Brian Di Palma wrote:
>>
>> It doesn't seem an issue that requires the ES6 module spec to have
>> something like default imports though.
>>
>> The compiler could output
>>
>> `
>> newModule({
>> default: require('minimist')
>> })
>> `
>>
>> and importers could do
>>
>> `import {default as minimist} from 'minimist';`
>>
>> Or you could have
>>
>> `
>> newModule({
>> minimist: require('minimist');
>> })
>> `
>>
>> and
>>
>> `import {minimist} from 'minimist';`
>>
>> depending on how the compiler is configured/written.
>>
>> This is implementation detail of compilers and loaders of legacy
>> systems as opposed to spec concerns.
>>
>> On Mon, Jul 21, 2014 at 6:50 PM, Guy Bedford wrote:
>> > Yes this is a bug that can be fixed at the compiler level. As you say we
>> > can
>> > generate a wrapper when loading a non-ES6 module in ES6:
>> >
>> > newModule({
>> > default: require('minimist')
>> > })
>> >
>> > We then conditionally add this wrapper based on detecting if the import
>> > is
>> > an ES6 module. This is the same method we have for AMD compilations at
>> > the
>> > moment, which seems to have been working well.
>> >
>> >
>> > On 21 July 2014 10:17, John Barton wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford
>> >> wrote:
>> >>>
>> >>> In Brian's case we actually need default exports. This is because the
>> >>> dynamic loader can't pick up the code he has written right now in ES6.
>> >>>
>> >>> This is how he is loading a NodeJS module in ES6:
>> >>>
>> >>> module minimist from 'minimist';
>> >>>
>> >>> In ES6 this means "give me the Module object with getters to the
>> >>> exports".
>> >>>
>> >>> But unfortunately in Traceur this is compiling into:
>> >>>
>> >>> var minimist = require('minimist');
>> >>>
>> >>> As a result the `module` syntax can possibly return him a 'function'
>> >>> or
>> >>> other non-Module object.
>> >>
>> >>
>> >> You seem to be saying "The traceur implementation of 'module' fails in
>> >> this case". It seems to me that Traceur could generate code which
>> >> would
>> >> wrap functions in Module objects. That is, this is not a fundamental
>> >> limit,
>> >> just an unreported bug.
>> >>
>> >>>
>> >>> Thus we have broken the ability to parse his code in the ES6 dynamic
>> >>> loader, as it is not capable of returning a non-Module object for a
>> >>> module
>> >>> import, which is pretty critical.
>> >>>
>> >>> Thus default export properties are critical to enabling this support
>> >>> path.
>> >>
>> >>
>> >> I believe that Caridy's point is: "fine, use dynamic linking".
>> >>
>> >>>
>> >>>
>> >>>
>> >>> On 21 July 2014 09:51, Caridy Patino wrote:
>>
>> Interoperability should not be a decisive factor here, we have fallen
>> into that trap before, the conclusion was to let Loader to handle
>> those
>> cases rather than trying to drive it from the perspective of the
>> module
>> syntax. Let's focus on what is best and what makes sense for the ES
>> Modules,
>> and keep the dynamic module systems out of the picture since we know
>> we have
>> a lot of flexibility with the loader to deal with those dynamic
>> modules.
>>
>> /caridy
>>
>>
>> On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma
>> wrote:
>> >
>> > Yep, that makes sense. Highly unlikely but still possible and could
>> > cause issues.
>> > No doubt you could complicate your compiler to deal with these edge
>> > cases but why force that?
>> >
>> > Yet more problems with default imports/exports. This feature doesn't
>> > seem worth its cost.
>> >
>> >
>> > On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
>> > wrote:
>> > > (woops hit reply instead of reply all)
>> > >
>> > > Because the `function mainThing(){}` might already have a method
>> > > named
>> > > helper or, more likely, t
Re: Re: Quantifying Default Exports
There are two issues here:
1) Is 'default' essential?
2) Should the spec. explicitly define commonjs loading?
Brian is claiming 1) no and 2) no. More important for me: does 2) require
1). Evidently not.
jjb
On Mon, Jul 21, 2014 at 1:34 PM, Brian Di Palma wrote:
> It doesn't seem an issue that requires the ES6 module spec to have
> something like default imports though.
>
> The compiler could output
>
> `
> newModule({
> default: require('minimist')
> })
> `
>
> and importers could do
>
> `import {default as minimist} from 'minimist';`
>
> Or you could have
>
> `
> newModule({
> minimist: require('minimist');
> })
> `
>
> and
>
> `import {minimist} from 'minimist';`
>
> depending on how the compiler is configured/written.
>
> This is implementation detail of compilers and loaders of legacy
> systems as opposed to spec concerns.
>
> On Mon, Jul 21, 2014 at 6:50 PM, Guy Bedford wrote:
> > Yes this is a bug that can be fixed at the compiler level. As you say we
> can
> > generate a wrapper when loading a non-ES6 module in ES6:
> >
> > newModule({
> > default: require('minimist')
> > })
> >
> > We then conditionally add this wrapper based on detecting if the import
> is
> > an ES6 module. This is the same method we have for AMD compilations at
> the
> > moment, which seems to have been working well.
> >
> >
> > On 21 July 2014 10:17, John Barton wrote:
> >>
> >>
> >>
> >>
> >> On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford
> >> wrote:
> >>>
> >>> In Brian's case we actually need default exports. This is because the
> >>> dynamic loader can't pick up the code he has written right now in ES6.
> >>>
> >>> This is how he is loading a NodeJS module in ES6:
> >>>
> >>> module minimist from 'minimist';
> >>>
> >>> In ES6 this means "give me the Module object with getters to the
> >>> exports".
> >>>
> >>> But unfortunately in Traceur this is compiling into:
> >>>
> >>> var minimist = require('minimist');
> >>>
> >>> As a result the `module` syntax can possibly return him a 'function' or
> >>> other non-Module object.
> >>
> >>
> >> You seem to be saying "The traceur implementation of 'module' fails in
> >> this case". It seems to me that Traceur could generate code which would
> >> wrap functions in Module objects. That is, this is not a fundamental
> limit,
> >> just an unreported bug.
> >>
> >>>
> >>> Thus we have broken the ability to parse his code in the ES6 dynamic
> >>> loader, as it is not capable of returning a non-Module object for a
> module
> >>> import, which is pretty critical.
> >>>
> >>> Thus default export properties are critical to enabling this support
> >>> path.
> >>
> >>
> >> I believe that Caridy's point is: "fine, use dynamic linking".
> >>
> >>>
> >>>
> >>>
> >>> On 21 July 2014 09:51, Caridy Patino wrote:
>
> Interoperability should not be a decisive factor here, we have fallen
> into that trap before, the conclusion was to let Loader to handle
> those
> cases rather than trying to drive it from the perspective of the
> module
> syntax. Let's focus on what is best and what makes sense for the ES
> Modules,
> and keep the dynamic module systems out of the picture since we know
> we have
> a lot of flexibility with the loader to deal with those dynamic
> modules.
>
> /caridy
>
>
> On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma
> wrote:
> >
> > Yep, that makes sense. Highly unlikely but still possible and could
> > cause issues.
> > No doubt you could complicate your compiler to deal with these edge
> > cases but why force that?
> >
> > Yet more problems with default imports/exports. This feature doesn't
> > seem worth its cost.
> >
> >
> > On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
> > wrote:
> > > (woops hit reply instead of reply all)
> > >
> > > Because the `function mainThing(){}` might already have a method
> > > named
> > > helper or, more likely, the named export is something like call or
> > > bind.
> > >
> > >
> > >
> > >
> > > On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma >
> > > wrote:
> > >>
> > >> On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
> > >> wrote:
> > >> > I have a CommonJS module which exports a single function
> > >> > ```js
> > >> > //cj.js
> > >> > module.exports = function (){}
> > >> > ```
> > >> >
> > >> > If I was to transform it into an ES6 module the best way to do
> so
> > >> > currently
> > >> > it so use a default export
> > >> >
> > >> > ```js
> > >> > //cj2es6.js
> > >> > export default function () {}
> > >> > ```
> > >> >
> > >> > now say I want to import those from another commonjs module,
> > >> > importing
> > >> > the
> > >> > first one is easy, but when importing the second one slightly
> less
> > >> > so,
> > >> > how
> > >> > should the loader treat that de
Re: Re: Quantifying Default Exports
It doesn't seem an issue that requires the ES6 module spec to have
something like default imports though.
The compiler could output
`
newModule({
default: require('minimist')
})
`
and importers could do
`import {default as minimist} from 'minimist';`
Or you could have
`
newModule({
minimist: require('minimist');
})
`
and
`import {minimist} from 'minimist';`
depending on how the compiler is configured/written.
This is implementation detail of compilers and loaders of legacy
systems as opposed to spec concerns.
On Mon, Jul 21, 2014 at 6:50 PM, Guy Bedford wrote:
> Yes this is a bug that can be fixed at the compiler level. As you say we can
> generate a wrapper when loading a non-ES6 module in ES6:
>
> newModule({
> default: require('minimist')
> })
>
> We then conditionally add this wrapper based on detecting if the import is
> an ES6 module. This is the same method we have for AMD compilations at the
> moment, which seems to have been working well.
>
>
> On 21 July 2014 10:17, John Barton wrote:
>>
>>
>>
>>
>> On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford
>> wrote:
>>>
>>> In Brian's case we actually need default exports. This is because the
>>> dynamic loader can't pick up the code he has written right now in ES6.
>>>
>>> This is how he is loading a NodeJS module in ES6:
>>>
>>> module minimist from 'minimist';
>>>
>>> In ES6 this means "give me the Module object with getters to the
>>> exports".
>>>
>>> But unfortunately in Traceur this is compiling into:
>>>
>>> var minimist = require('minimist');
>>>
>>> As a result the `module` syntax can possibly return him a 'function' or
>>> other non-Module object.
>>
>>
>> You seem to be saying "The traceur implementation of 'module' fails in
>> this case". It seems to me that Traceur could generate code which would
>> wrap functions in Module objects. That is, this is not a fundamental limit,
>> just an unreported bug.
>>
>>>
>>> Thus we have broken the ability to parse his code in the ES6 dynamic
>>> loader, as it is not capable of returning a non-Module object for a module
>>> import, which is pretty critical.
>>>
>>> Thus default export properties are critical to enabling this support
>>> path.
>>
>>
>> I believe that Caridy's point is: "fine, use dynamic linking".
>>
>>>
>>>
>>>
>>> On 21 July 2014 09:51, Caridy Patino wrote:
Interoperability should not be a decisive factor here, we have fallen
into that trap before, the conclusion was to let Loader to handle those
cases rather than trying to drive it from the perspective of the module
syntax. Let's focus on what is best and what makes sense for the ES
Modules,
and keep the dynamic module systems out of the picture since we know we
have
a lot of flexibility with the loader to deal with those dynamic modules.
/caridy
On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma
wrote:
>
> Yep, that makes sense. Highly unlikely but still possible and could
> cause issues.
> No doubt you could complicate your compiler to deal with these edge
> cases but why force that?
>
> Yet more problems with default imports/exports. This feature doesn't
> seem worth its cost.
>
>
> On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
> wrote:
> > (woops hit reply instead of reply all)
> >
> > Because the `function mainThing(){}` might already have a method
> > named
> > helper or, more likely, the named export is something like call or
> > bind.
> >
> >
> >
> >
> > On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma
> > wrote:
> >>
> >> On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
> >> wrote:
> >> > I have a CommonJS module which exports a single function
> >> > ```js
> >> > //cj.js
> >> > module.exports = function (){}
> >> > ```
> >> >
> >> > If I was to transform it into an ES6 module the best way to do so
> >> > currently
> >> > it so use a default export
> >> >
> >> > ```js
> >> > //cj2es6.js
> >> > export default function () {}
> >> > ```
> >> >
> >> > now say I want to import those from another commonjs module,
> >> > importing
> >> > the
> >> > first one is easy, but when importing the second one slightly less
> >> > so,
> >> > how
> >> > should the loader treat that default export, a easy solution for
> >> > this
> >> > case
> >> > is to simply have default exports act the same as a module.exports
> >> >
> >> > But then what would you do about es6 modules that use default and
> >> > named
> >> > exports like the example at http://jsmodules.io/ which can be
> >> > sumerized
> >> > as
> >> >
> >> > ```js
> >> >
> >> > export default function mainThing(){}
> >> > export function helper (){};
> >> >
> >> > , if we return a default export if it exists then there is no way
> >>
Re: Re: Quantifying Default Exports
Yes this is a bug that can be fixed at the compiler level. As you say we
can generate a wrapper when loading a non-ES6 module in ES6:
newModule({
default: require('minimist')
})
We then conditionally add this wrapper based on detecting if the import is
an ES6 module. This is the same method we have for AMD compilations at the
moment, which seems to have been working well.
On 21 July 2014 10:17, John Barton wrote:
>
>
>
> On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford
> wrote:
>
>> In Brian's case we actually need default exports. This is because the
>> dynamic loader can't pick up the code he has written right now in ES6.
>>
>> This is how he is loading a NodeJS module in ES6:
>>
>> module minimist from 'minimist';
>>
>> In ES6 this means "give me the Module object with getters to the exports".
>>
>> But unfortunately in Traceur this is compiling into:
>>
>> var minimist = require('minimist');
>>
>> As a result the `module` syntax can possibly return him a 'function' or
>> other non-Module object.
>>
>
> You seem to be saying "The traceur implementation of 'module' fails in
> this case". It seems to me that Traceur could generate code which would
> wrap functions in Module objects. That is, this is not a fundamental
> limit, just an unreported bug.
>
>
>> Thus we have broken the ability to parse his code in the ES6 dynamic
>> loader, as it is not capable of returning a non-Module object for a module
>> import, which is pretty critical.
>>
>> Thus default export properties are critical to enabling this support path.
>>
>
> I believe that Caridy's point is: "fine, use dynamic linking".
>
>
>>
>>
>> On 21 July 2014 09:51, Caridy Patino wrote:
>>
>>> Interoperability should not be a decisive factor here, we have fallen
>>> into that trap before, the conclusion was to let Loader to handle those
>>> cases rather than trying to drive it from the perspective of the module
>>> syntax. Let's focus on what is best and what makes sense for the ES
>>> Modules, and keep the dynamic module systems out of the picture since we
>>> know we have a lot of flexibility with the loader to deal with those
>>> dynamic modules.
>>>
>>> /caridy
>>>
>>>
>>> On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma
>>> wrote:
>>>
Yep, that makes sense. Highly unlikely but still possible and could
cause issues.
No doubt you could complicate your compiler to deal with these edge
cases but why force that?
Yet more problems with default imports/exports. This feature doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
wrote:
> (woops hit reply instead of reply all)
>
> Because the `function mainThing(){}` might already have a method named
> helper or, more likely, the named export is something like call or
bind.
>
>
>
>
> On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma
wrote:
>>
>> On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
>> wrote:
>> > I have a CommonJS module which exports a single function
>> > ```js
>> > //cj.js
>> > module.exports = function (){}
>> > ```
>> >
>> > If I was to transform it into an ES6 module the best way to do so
>> > currently
>> > it so use a default export
>> >
>> > ```js
>> > //cj2es6.js
>> > export default function () {}
>> > ```
>> >
>> > now say I want to import those from another commonjs module,
importing
>> > the
>> > first one is easy, but when importing the second one slightly less
so,
>> > how
>> > should the loader treat that default export, a easy solution for
this
>> > case
>> > is to simply have default exports act the same as a module.exports
>> >
>> > But then what would you do about es6 modules that use default and
named
>> > exports like the example at http://jsmodules.io/ which can be
sumerized
>> > as
>> >
>> > ```js
>> >
>> > export default function mainThing(){}
>> > export function helper (){};
>> >
>> > , if we return a default export if it exists then there is no way
to
>> > access
>> > the named exports.
>>
>> As mentioned in the GitHub issue I don't see why you couldn't
compile to
>>
>> `
>> module.export = function mainThing(){};
>>
>> module.export.helper = function(){};
>> `
>>
>> Allowing access to the default and named.
>>
>> >
>> > So in that case it would make more sense to treat default as just
>> > another
>> > export name. But if we do that then that means that if we go back
to
>> > our
>> > second example
>> >
>> > ```js
>> > //cj2es6.js
>> > export default function () {}
>> > ```
>> >
>> > if that was to be treated that way then importing it from another
>> > commonjs
>> > mod
Re: Re: Quantifying Default Exports
On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford wrote:
> In Brian's case we actually need default exports. This is because the
> dynamic loader can't pick up the code he has written right now in ES6.
>
> This is how he is loading a NodeJS module in ES6:
>
> module minimist from 'minimist';
>
> In ES6 this means "give me the Module object with getters to the exports".
>
> But unfortunately in Traceur this is compiling into:
>
> var minimist = require('minimist');
>
> As a result the `module` syntax can possibly return him a 'function' or
> other non-Module object.
>
You seem to be saying "The traceur implementation of 'module' fails in this
case". It seems to me that Traceur could generate code which would wrap
functions in Module objects. That is, this is not a fundamental limit,
just an unreported bug.
> Thus we have broken the ability to parse his code in the ES6 dynamic
> loader, as it is not capable of returning a non-Module object for a module
> import, which is pretty critical.
>
> Thus default export properties are critical to enabling this support path.
>
I believe that Caridy's point is: "fine, use dynamic linking".
>
>
> On 21 July 2014 09:51, Caridy Patino wrote:
>
>> Interoperability should not be a decisive factor here, we have fallen
>> into that trap before, the conclusion was to let Loader to handle those
>> cases rather than trying to drive it from the perspective of the module
>> syntax. Let's focus on what is best and what makes sense for the ES
>> Modules, and keep the dynamic module systems out of the picture since we
>> know we have a lot of flexibility with the loader to deal with those
>> dynamic modules.
>>
>> /caridy
>>
>>
>> On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma
>> wrote:
>>
>>> Yep, that makes sense. Highly unlikely but still possible and could
>>> cause issues.
>>> No doubt you could complicate your compiler to deal with these edge
>>> cases but why force that?
>>>
>>> Yet more problems with default imports/exports. This feature doesn't
>>> seem worth its cost.
>>>
>>>
>>> On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
>>> wrote:
>>> > (woops hit reply instead of reply all)
>>> >
>>> > Because the `function mainThing(){}` might already have a method named
>>> > helper or, more likely, the named export is something like call or
>>> bind.
>>> >
>>> >
>>> >
>>> >
>>> > On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma
>>> wrote:
>>> >>
>>> >> On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
>>> >> wrote:
>>> >> > I have a CommonJS module which exports a single function
>>> >> > ```js
>>> >> > //cj.js
>>> >> > module.exports = function (){}
>>> >> > ```
>>> >> >
>>> >> > If I was to transform it into an ES6 module the best way to do so
>>> >> > currently
>>> >> > it so use a default export
>>> >> >
>>> >> > ```js
>>> >> > //cj2es6.js
>>> >> > export default function () {}
>>> >> > ```
>>> >> >
>>> >> > now say I want to import those from another commonjs module,
>>> importing
>>> >> > the
>>> >> > first one is easy, but when importing the second one slightly less
>>> so,
>>> >> > how
>>> >> > should the loader treat that default export, a easy solution for
>>> this
>>> >> > case
>>> >> > is to simply have default exports act the same as a module.exports
>>> >> >
>>> >> > But then what would you do about es6 modules that use default and
>>> named
>>> >> > exports like the example at http://jsmodules.io/ which can be
>>> sumerized
>>> >> > as
>>> >> >
>>> >> > ```js
>>> >> >
>>> >> > export default function mainThing(){}
>>> >> > export function helper (){};
>>> >> >
>>> >> > , if we return a default export if it exists then there is no way to
>>> >> > access
>>> >> > the named exports.
>>> >>
>>> >> As mentioned in the GitHub issue I don't see why you couldn't compile
>>> to
>>> >>
>>> >> `
>>> >> module.export = function mainThing(){};
>>> >>
>>> >> module.export.helper = function(){};
>>> >> `
>>> >>
>>> >> Allowing access to the default and named.
>>> >>
>>> >> >
>>> >> > So in that case it would make more sense to treat default as just
>>> >> > another
>>> >> > export name. But if we do that then that means that if we go back
>>> to
>>> >> > our
>>> >> > second example
>>> >> >
>>> >> > ```js
>>> >> > //cj2es6.js
>>> >> > export default function () {}
>>> >> > ```
>>> >> >
>>> >> > if that was to be treated that way then importing it from another
>>> >> > commonjs
>>> >> > module would be make it be equivalent to
>>> >> >
>>> >> > ```js
>>> >> > //cj2es62cj.js
>>> >> > exports.default = function (){}
>>> >> > ```
>>> >> >
>>> >> > In other words treating default as a regular name prevents you from
>>> >> > losslessly converting commonjs in a backwards compatible way.
>>> >> >
>>> >> > Making named and default exports be mutually exclusive would mean
>>> that
>>> >> > you
>>> >> > could treat default export like module.exports.
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma
>>> >> > wrote:
>>> >> >>
>>> >> >> On Mon,
Re: Re: Quantifying Default Exports
In Brian's case we actually need default exports. This is because the
dynamic loader can't pick up the code he has written right now in ES6.
This is how he is loading a NodeJS module in ES6:
module minimist from 'minimist';
In ES6 this means "give me the Module object with getters to the exports".
But unfortunately in Traceur this is compiling into:
var minimist = require('minimist');
As a result the `module` syntax can possibly return him a 'function' or
other non-Module object. Thus we have broken the ability to parse his code
in the ES6 dynamic loader, as it is not capable of returning a non-Module
object for a module import, which is pretty critical.
Thus default export properties are critical to enabling this support path.
On 21 July 2014 09:51, Caridy Patino wrote:
> Interoperability should not be a decisive factor here, we have fallen into
> that trap before, the conclusion was to let Loader to handle those cases
> rather than trying to drive it from the perspective of the module syntax.
> Let's focus on what is best and what makes sense for the ES Modules, and
> keep the dynamic module systems out of the picture since we know we have a
> lot of flexibility with the loader to deal with those dynamic modules.
>
> /caridy
>
>
> On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma wrote:
>
>> Yep, that makes sense. Highly unlikely but still possible and could
>> cause issues.
>> No doubt you could complicate your compiler to deal with these edge
>> cases but why force that?
>>
>> Yet more problems with default imports/exports. This feature doesn't
>> seem worth its cost.
>>
>>
>> On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
>> wrote:
>> > (woops hit reply instead of reply all)
>> >
>> > Because the `function mainThing(){}` might already have a method named
>> > helper or, more likely, the named export is something like call or bind.
>> >
>> >
>> >
>> >
>> > On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma
>> wrote:
>> >>
>> >> On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
>> >> wrote:
>> >> > I have a CommonJS module which exports a single function
>> >> > ```js
>> >> > //cj.js
>> >> > module.exports = function (){}
>> >> > ```
>> >> >
>> >> > If I was to transform it into an ES6 module the best way to do so
>> >> > currently
>> >> > it so use a default export
>> >> >
>> >> > ```js
>> >> > //cj2es6.js
>> >> > export default function () {}
>> >> > ```
>> >> >
>> >> > now say I want to import those from another commonjs module,
>> importing
>> >> > the
>> >> > first one is easy, but when importing the second one slightly less
>> so,
>> >> > how
>> >> > should the loader treat that default export, a easy solution for this
>> >> > case
>> >> > is to simply have default exports act the same as a module.exports
>> >> >
>> >> > But then what would you do about es6 modules that use default and
>> named
>> >> > exports like the example at http://jsmodules.io/ which can be
>> sumerized
>> >> > as
>> >> >
>> >> > ```js
>> >> >
>> >> > export default function mainThing(){}
>> >> > export function helper (){};
>> >> >
>> >> > , if we return a default export if it exists then there is no way to
>> >> > access
>> >> > the named exports.
>> >>
>> >> As mentioned in the GitHub issue I don't see why you couldn't compile
>> to
>> >>
>> >> `
>> >> module.export = function mainThing(){};
>> >>
>> >> module.export.helper = function(){};
>> >> `
>> >>
>> >> Allowing access to the default and named.
>> >>
>> >> >
>> >> > So in that case it would make more sense to treat default as just
>> >> > another
>> >> > export name. But if we do that then that means that if we go back to
>> >> > our
>> >> > second example
>> >> >
>> >> > ```js
>> >> > //cj2es6.js
>> >> > export default function () {}
>> >> > ```
>> >> >
>> >> > if that was to be treated that way then importing it from another
>> >> > commonjs
>> >> > module would be make it be equivalent to
>> >> >
>> >> > ```js
>> >> > //cj2es62cj.js
>> >> > exports.default = function (){}
>> >> > ```
>> >> >
>> >> > In other words treating default as a regular name prevents you from
>> >> > losslessly converting commonjs in a backwards compatible way.
>> >> >
>> >> > Making named and default exports be mutually exclusive would mean
>> that
>> >> > you
>> >> > could treat default export like module.exports.
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma
>> >> > wrote:
>> >> >>
>> >> >> On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
>> >> >> wrote:
>> >> >> > that won't help if module.exports is a function
>> >> >>
>> >> >> That's exactly what `minimist` is, works just fine.
>> >> >>
>> >> >> https://github.com/substack/minimist/blob/master/index.js
>> >> >>
>> >> >> >
>> >> >> > Overall the import/exports semantics of es6 and cjs modules would
>> be
>> >> >> > compatible if mixing named and default exports was prohibited, but
>> >> >> > the
>> >> >> > ability to have both is hard to represent in cjs modules.
>> >> >>
>> >> >> Don't
Re: Re: Quantifying Default Exports
Interoperability should not be a decisive factor here, we have fallen into
that trap before, the conclusion was to let Loader to handle those cases
rather than trying to drive it from the perspective of the module syntax.
Let's focus on what is best and what makes sense for the ES Modules, and
keep the dynamic module systems out of the picture since we know we have a
lot of flexibility with the loader to deal with those dynamic modules.
/caridy
On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma wrote:
> Yep, that makes sense. Highly unlikely but still possible and could
> cause issues.
> No doubt you could complicate your compiler to deal with these edge
> cases but why force that?
>
> Yet more problems with default imports/exports. This feature doesn't
> seem worth its cost.
>
>
> On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
> wrote:
> > (woops hit reply instead of reply all)
> >
> > Because the `function mainThing(){}` might already have a method named
> > helper or, more likely, the named export is something like call or bind.
> >
> >
> >
> >
> > On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma
> wrote:
> >>
> >> On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
> >> wrote:
> >> > I have a CommonJS module which exports a single function
> >> > ```js
> >> > //cj.js
> >> > module.exports = function (){}
> >> > ```
> >> >
> >> > If I was to transform it into an ES6 module the best way to do so
> >> > currently
> >> > it so use a default export
> >> >
> >> > ```js
> >> > //cj2es6.js
> >> > export default function () {}
> >> > ```
> >> >
> >> > now say I want to import those from another commonjs module, importing
> >> > the
> >> > first one is easy, but when importing the second one slightly less so,
> >> > how
> >> > should the loader treat that default export, a easy solution for this
> >> > case
> >> > is to simply have default exports act the same as a module.exports
> >> >
> >> > But then what would you do about es6 modules that use default and
> named
> >> > exports like the example at http://jsmodules.io/ which can be
> sumerized
> >> > as
> >> >
> >> > ```js
> >> >
> >> > export default function mainThing(){}
> >> > export function helper (){};
> >> >
> >> > , if we return a default export if it exists then there is no way to
> >> > access
> >> > the named exports.
> >>
> >> As mentioned in the GitHub issue I don't see why you couldn't compile to
> >>
> >> `
> >> module.export = function mainThing(){};
> >>
> >> module.export.helper = function(){};
> >> `
> >>
> >> Allowing access to the default and named.
> >>
> >> >
> >> > So in that case it would make more sense to treat default as just
> >> > another
> >> > export name. But if we do that then that means that if we go back to
> >> > our
> >> > second example
> >> >
> >> > ```js
> >> > //cj2es6.js
> >> > export default function () {}
> >> > ```
> >> >
> >> > if that was to be treated that way then importing it from another
> >> > commonjs
> >> > module would be make it be equivalent to
> >> >
> >> > ```js
> >> > //cj2es62cj.js
> >> > exports.default = function (){}
> >> > ```
> >> >
> >> > In other words treating default as a regular name prevents you from
> >> > losslessly converting commonjs in a backwards compatible way.
> >> >
> >> > Making named and default exports be mutually exclusive would mean that
> >> > you
> >> > could treat default export like module.exports.
> >> >
> >> >
> >> >
> >> > On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma
> >> > wrote:
> >> >>
> >> >> On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
> >> >> wrote:
> >> >> > that won't help if module.exports is a function
> >> >>
> >> >> That's exactly what `minimist` is, works just fine.
> >> >>
> >> >> https://github.com/substack/minimist/blob/master/index.js
> >> >>
> >> >> >
> >> >> > Overall the import/exports semantics of es6 and cjs modules would
> be
> >> >> > compatible if mixing named and default exports was prohibited, but
> >> >> > the
> >> >> > ability to have both is hard to represent in cjs modules.
> >> >>
> >> >> Don't understand this, do you have some code examples? I can't see
> why
> >> >> that would be the case.
> >> >>
> >> >> >
> >> >> >
> >> >> > On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma >
> >> >> > wrote:
> >> >> >>
> >> >> >> Which shows the how the backward compatability argument for
> default
> >> >> >> export/imports doesn't stand up.
> >> >> >>
> >> >> >> If you want to import `module.exports` then use the the `module`
> >> >> >> form
> >> >> >> if you want named imports use the named form.
> >> >> >> Default import/exports are generating nothing more then
> complexity,
> >> >> >> confusion and not serving their intended goals.
> >> >> >>
> >> >> >> On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
> >> >> >> wrote:
> >> >> >> > similar discussion at systemjs
> >> >> >> > https://github.com/systemjs/systemjs/issues/131 which boils
> down
> >> >> >> > to
> >> >> >> > if a
> >> >> >> > CJS
> >> >> >> > module imports an ES6 modul
Re: Re: Quantifying Default Exports
Yep, that makes sense. Highly unlikely but still possible and could
cause issues.
No doubt you could complicate your compiler to deal with these edge
cases but why force that?
Yet more problems with default imports/exports. This feature doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
wrote:
> (woops hit reply instead of reply all)
>
> Because the `function mainThing(){}` might already have a method named
> helper or, more likely, the named export is something like call or bind.
>
>
>
>
> On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma wrote:
>>
>> On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
>> wrote:
>> > I have a CommonJS module which exports a single function
>> > ```js
>> > //cj.js
>> > module.exports = function (){}
>> > ```
>> >
>> > If I was to transform it into an ES6 module the best way to do so
>> > currently
>> > it so use a default export
>> >
>> > ```js
>> > //cj2es6.js
>> > export default function () {}
>> > ```
>> >
>> > now say I want to import those from another commonjs module, importing
>> > the
>> > first one is easy, but when importing the second one slightly less so,
>> > how
>> > should the loader treat that default export, a easy solution for this
>> > case
>> > is to simply have default exports act the same as a module.exports
>> >
>> > But then what would you do about es6 modules that use default and named
>> > exports like the example at http://jsmodules.io/ which can be sumerized
>> > as
>> >
>> > ```js
>> >
>> > export default function mainThing(){}
>> > export function helper (){};
>> >
>> > , if we return a default export if it exists then there is no way to
>> > access
>> > the named exports.
>>
>> As mentioned in the GitHub issue I don't see why you couldn't compile to
>>
>> `
>> module.export = function mainThing(){};
>>
>> module.export.helper = function(){};
>> `
>>
>> Allowing access to the default and named.
>>
>> >
>> > So in that case it would make more sense to treat default as just
>> > another
>> > export name. But if we do that then that means that if we go back to
>> > our
>> > second example
>> >
>> > ```js
>> > //cj2es6.js
>> > export default function () {}
>> > ```
>> >
>> > if that was to be treated that way then importing it from another
>> > commonjs
>> > module would be make it be equivalent to
>> >
>> > ```js
>> > //cj2es62cj.js
>> > exports.default = function (){}
>> > ```
>> >
>> > In other words treating default as a regular name prevents you from
>> > losslessly converting commonjs in a backwards compatible way.
>> >
>> > Making named and default exports be mutually exclusive would mean that
>> > you
>> > could treat default export like module.exports.
>> >
>> >
>> >
>> > On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma
>> > wrote:
>> >>
>> >> On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
>> >> wrote:
>> >> > that won't help if module.exports is a function
>> >>
>> >> That's exactly what `minimist` is, works just fine.
>> >>
>> >> https://github.com/substack/minimist/blob/master/index.js
>> >>
>> >> >
>> >> > Overall the import/exports semantics of es6 and cjs modules would be
>> >> > compatible if mixing named and default exports was prohibited, but
>> >> > the
>> >> > ability to have both is hard to represent in cjs modules.
>> >>
>> >> Don't understand this, do you have some code examples? I can't see why
>> >> that would be the case.
>> >>
>> >> >
>> >> >
>> >> > On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma
>> >> > wrote:
>> >> >>
>> >> >> Which shows the how the backward compatability argument for default
>> >> >> export/imports doesn't stand up.
>> >> >>
>> >> >> If you want to import `module.exports` then use the the `module`
>> >> >> form
>> >> >> if you want named imports use the named form.
>> >> >> Default import/exports are generating nothing more then complexity,
>> >> >> confusion and not serving their intended goals.
>> >> >>
>> >> >> On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
>> >> >> wrote:
>> >> >> > similar discussion at systemjs
>> >> >> > https://github.com/systemjs/systemjs/issues/131 which boils down
>> >> >> > to
>> >> >> > if a
>> >> >> > CJS
>> >> >> > module imports an ES6 module that has a key named default, what
>> >> >> > should
>> >> >> > the
>> >> >> > default behavior be.
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma
>> >> >> >
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> It's using traceur and building the modules to CJS, the project
>> >> >> >> uses
>> >> >> >> other non transpiled CJS modules.
>> >> >> >>
>> >> >> >> The only thing traceur could do here is compile the imports into
>> >> >> >> a
>> >> >> >> check for the named export `default` and use that if it exists.
>> >> >> >> If it doesn't then simply return the CJS module object.
>> >> >> >>
>> >> >> >> Here is the output from traceur
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> https://github.com/briandipalma/global-compiler/blob/master/out/index.js
>> >>
Re: Re: Quantifying Default Exports
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method named
helper or, more likely, the named export is something like call or bind.
On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma wrote:
> On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
> wrote:
> > I have a CommonJS module which exports a single function
> > ```js
> > //cj.js
> > module.exports = function (){}
> > ```
> >
> > If I was to transform it into an ES6 module the best way to do so
> currently
> > it so use a default export
> >
> > ```js
> > //cj2es6.js
> > export default function () {}
> > ```
> >
> > now say I want to import those from another commonjs module, importing
> the
> > first one is easy, but when importing the second one slightly less so,
> how
> > should the loader treat that default export, a easy solution for this
> case
> > is to simply have default exports act the same as a module.exports
> >
> > But then what would you do about es6 modules that use default and named
> > exports like the example at http://jsmodules.io/ which can be sumerized
> as
> >
> > ```js
> >
> > export default function mainThing(){}
> > export function helper (){};
> >
> > , if we return a default export if it exists then there is no way to
> access
> > the named exports.
>
> As mentioned in the GitHub issue I don't see why you couldn't compile to
>
> `
> module.export = function mainThing(){};
>
> module.export.helper = function(){};
> `
>
> Allowing access to the default and named.
>
> >
> > So in that case it would make more sense to treat default as just another
> > export name. But if we do that then that means that if we go back to our
> > second example
> >
> > ```js
> > //cj2es6.js
> > export default function () {}
> > ```
> >
> > if that was to be treated that way then importing it from another
> commonjs
> > module would be make it be equivalent to
> >
> > ```js
> > //cj2es62cj.js
> > exports.default = function (){}
> > ```
> >
> > In other words treating default as a regular name prevents you from
> > losslessly converting commonjs in a backwards compatible way.
> >
> > Making named and default exports be mutually exclusive would mean that
> you
> > could treat default export like module.exports.
> >
> >
> >
> > On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma
> wrote:
> >>
> >> On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
> >> wrote:
> >> > that won't help if module.exports is a function
> >>
> >> That's exactly what `minimist` is, works just fine.
> >>
> >> https://github.com/substack/minimist/blob/master/index.js
> >>
> >> >
> >> > Overall the import/exports semantics of es6 and cjs modules would be
> >> > compatible if mixing named and default exports was prohibited, but the
> >> > ability to have both is hard to represent in cjs modules.
> >>
> >> Don't understand this, do you have some code examples? I can't see why
> >> that would be the case.
> >>
> >> >
> >> >
> >> > On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma
> >> > wrote:
> >> >>
> >> >> Which shows the how the backward compatability argument for default
> >> >> export/imports doesn't stand up.
> >> >>
> >> >> If you want to import `module.exports` then use the the `module` form
> >> >> if you want named imports use the named form.
> >> >> Default import/exports are generating nothing more then complexity,
> >> >> confusion and not serving their intended goals.
> >> >>
> >> >> On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
> >> >> wrote:
> >> >> > similar discussion at systemjs
> >> >> > https://github.com/systemjs/systemjs/issues/131 which boils down
> to
> >> >> > if a
> >> >> > CJS
> >> >> > module imports an ES6 module that has a key named default, what
> >> >> > should
> >> >> > the
> >> >> > default behavior be.
> >> >> >
> >> >> >
> >> >> > On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma >
> >> >> > wrote:
> >> >> >>
> >> >> >> It's using traceur and building the modules to CJS, the project
> uses
> >> >> >> other non transpiled CJS modules.
> >> >> >>
> >> >> >> The only thing traceur could do here is compile the imports into a
> >> >> >> check for the named export `default` and use that if it exists.
> >> >> >> If it doesn't then simply return the CJS module object.
> >> >> >>
> >> >> >> Here is the output from traceur
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> https://github.com/briandipalma/global-compiler/blob/master/out/index.js
> >> >> >>
> >> >> >> The relevant line would be
> >> >> >>
> >> >> >> `var minimist = require('minimist');`
> >> >> >>
> >> >> >> For default import from a CJS module you'd need to output
> >> >> >>
> >> >> >> `
> >> >> >> var minimist = require('minimist');
> >> >> >> if (minimist.default) {
> >> >> >> minimist = minimist.default;
> >> >> >> }
> >> >> >> `
> >> >> >>
> >> >> >> Is that what you think traceur should do?
> >> >> >>
> >> >> >> On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
> >> >> >> wrote:
> >> >> >> >
> >> >> >> >> On Saturday, July 19, 2014 1:
Re: Re: Quantifying Default Exports
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
wrote:
> I have a CommonJS module which exports a single function
> ```js
> //cj.js
> module.exports = function (){}
> ```
>
> If I was to transform it into an ES6 module the best way to do so currently
> it so use a default export
>
> ```js
> //cj2es6.js
> export default function () {}
> ```
>
> now say I want to import those from another commonjs module, importing the
> first one is easy, but when importing the second one slightly less so, how
> should the loader treat that default export, a easy solution for this case
> is to simply have default exports act the same as a module.exports
>
> But then what would you do about es6 modules that use default and named
> exports like the example at http://jsmodules.io/ which can be sumerized as
>
> ```js
>
> export default function mainThing(){}
> export function helper (){};
>
> , if we return a default export if it exists then there is no way to access
> the named exports.
As mentioned in the GitHub issue I don't see why you couldn't compile to
`
module.export = function mainThing(){};
module.export.helper = function(){};
`
Allowing access to the default and named.
>
> So in that case it would make more sense to treat default as just another
> export name. But if we do that then that means that if we go back to our
> second example
>
> ```js
> //cj2es6.js
> export default function () {}
> ```
>
> if that was to be treated that way then importing it from another commonjs
> module would be make it be equivalent to
>
> ```js
> //cj2es62cj.js
> exports.default = function (){}
> ```
>
> In other words treating default as a regular name prevents you from
> losslessly converting commonjs in a backwards compatible way.
>
> Making named and default exports be mutually exclusive would mean that you
> could treat default export like module.exports.
>
>
>
> On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma wrote:
>>
>> On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
>> wrote:
>> > that won't help if module.exports is a function
>>
>> That's exactly what `minimist` is, works just fine.
>>
>> https://github.com/substack/minimist/blob/master/index.js
>>
>> >
>> > Overall the import/exports semantics of es6 and cjs modules would be
>> > compatible if mixing named and default exports was prohibited, but the
>> > ability to have both is hard to represent in cjs modules.
>>
>> Don't understand this, do you have some code examples? I can't see why
>> that would be the case.
>>
>> >
>> >
>> > On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma
>> > wrote:
>> >>
>> >> Which shows the how the backward compatability argument for default
>> >> export/imports doesn't stand up.
>> >>
>> >> If you want to import `module.exports` then use the the `module` form
>> >> if you want named imports use the named form.
>> >> Default import/exports are generating nothing more then complexity,
>> >> confusion and not serving their intended goals.
>> >>
>> >> On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
>> >> wrote:
>> >> > similar discussion at systemjs
>> >> > https://github.com/systemjs/systemjs/issues/131 which boils down to
>> >> > if a
>> >> > CJS
>> >> > module imports an ES6 module that has a key named default, what
>> >> > should
>> >> > the
>> >> > default behavior be.
>> >> >
>> >> >
>> >> > On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma
>> >> > wrote:
>> >> >>
>> >> >> It's using traceur and building the modules to CJS, the project uses
>> >> >> other non transpiled CJS modules.
>> >> >>
>> >> >> The only thing traceur could do here is compile the imports into a
>> >> >> check for the named export `default` and use that if it exists.
>> >> >> If it doesn't then simply return the CJS module object.
>> >> >>
>> >> >> Here is the output from traceur
>> >> >>
>> >> >>
>> >> >>
>> >> >> https://github.com/briandipalma/global-compiler/blob/master/out/index.js
>> >> >>
>> >> >> The relevant line would be
>> >> >>
>> >> >> `var minimist = require('minimist');`
>> >> >>
>> >> >> For default import from a CJS module you'd need to output
>> >> >>
>> >> >> `
>> >> >> var minimist = require('minimist');
>> >> >> if (minimist.default) {
>> >> >> minimist = minimist.default;
>> >> >> }
>> >> >> `
>> >> >>
>> >> >> Is that what you think traceur should do?
>> >> >>
>> >> >> On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
>> >> >> wrote:
>> >> >> >
>> >> >> >> On Saturday, July 19, 2014 1:53 PM, Brian Di Palma
>> >> >> >>
>> >> >> >> wrote:
>> >> >> >
>> >> >> >> When an npm package exports a named identifier it's trivial to
>> >> >> >> use
>> >> >> >> it
>> >> >> > in an ES6 module.
>> >> >> >
>> >> >> > import {
>> >> >> > parse,
>> >> >> > print
>> >> >> > } from 'recast';
>> >> >> >
>> >> >> >> When on the other hand it sets its export on `module.exports`
>> >> >> >> default
>> >> >> > exports provide no help at all.
>> >> >> >
>> >> >> > This sounds like an issue in your transpiler. Ideally CJS modules
>> >> >> > inside
>>
Re: Re: Quantifying Default Exports
> > > Making named and default exports be mutually exclusive would mean that you > could treat default export like module.exports. > Or just drain the swamp and remove default exports, rather than fighting these alligators. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those from another commonjs module, importing the
first one is easy, but when importing the second one slightly less so, how
should the loader treat that default export, a easy solution for this case
is to simply have default exports act the same as a module.exports
But then what would you do about es6 modules that use default and named
exports like the example at http://jsmodules.io/ which can be sumerized as
```js
export default function mainThing(){}
export function helper (){};
, if we return a default export if it exists then there is no way to access
the named exports.
So in that case it would make more sense to treat default as just another
export name. But if we do that then that means that if we go back to our
second example
```js
//cj2es6.js
export default function () {}
```
if that was to be treated that way then importing it from another commonjs
module would be make it be equivalent to
```js
//cj2es62cj.js
exports.default = function (){}
```
In other words treating default as a regular name prevents you from
losslessly converting commonjs in a backwards compatible way.
Making named and default exports be mutually exclusive would mean that you
could treat default export like module.exports.
On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma wrote:
> On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
> wrote:
> > that won't help if module.exports is a function
>
> That's exactly what `minimist` is, works just fine.
>
> https://github.com/substack/minimist/blob/master/index.js
>
> >
> > Overall the import/exports semantics of es6 and cjs modules would be
> > compatible if mixing named and default exports was prohibited, but the
> > ability to have both is hard to represent in cjs modules.
>
> Don't understand this, do you have some code examples? I can't see why
> that would be the case.
>
> >
> >
> > On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma
> wrote:
> >>
> >> Which shows the how the backward compatability argument for default
> >> export/imports doesn't stand up.
> >>
> >> If you want to import `module.exports` then use the the `module` form
> >> if you want named imports use the named form.
> >> Default import/exports are generating nothing more then complexity,
> >> confusion and not serving their intended goals.
> >>
> >> On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
> >> wrote:
> >> > similar discussion at systemjs
> >> > https://github.com/systemjs/systemjs/issues/131 which boils down to
> if a
> >> > CJS
> >> > module imports an ES6 module that has a key named default, what should
> >> > the
> >> > default behavior be.
> >> >
> >> >
> >> > On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma
> >> > wrote:
> >> >>
> >> >> It's using traceur and building the modules to CJS, the project uses
> >> >> other non transpiled CJS modules.
> >> >>
> >> >> The only thing traceur could do here is compile the imports into a
> >> >> check for the named export `default` and use that if it exists.
> >> >> If it doesn't then simply return the CJS module object.
> >> >>
> >> >> Here is the output from traceur
> >> >>
> >> >>
> >> >>
> https://github.com/briandipalma/global-compiler/blob/master/out/index.js
> >> >>
> >> >> The relevant line would be
> >> >>
> >> >> `var minimist = require('minimist');`
> >> >>
> >> >> For default import from a CJS module you'd need to output
> >> >>
> >> >> `
> >> >> var minimist = require('minimist');
> >> >> if (minimist.default) {
> >> >> minimist = minimist.default;
> >> >> }
> >> >> `
> >> >>
> >> >> Is that what you think traceur should do?
> >> >>
> >> >> On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
> >> >> wrote:
> >> >> >
> >> >> >> On Saturday, July 19, 2014 1:53 PM, Brian Di Palma
> >> >> >>
> >> >> >> wrote:
> >> >> >
> >> >> >> When an npm package exports a named identifier it's trivial to use
> >> >> >> it
> >> >> > in an ES6 module.
> >> >> >
> >> >> > import {
> >> >> > parse,
> >> >> > print
> >> >> > } from 'recast';
> >> >> >
> >> >> >> When on the other hand it sets its export on `module.exports`
> >> >> >> default
> >> >> > exports provide no help at all.
> >> >> >
> >> >> > This sounds like an issue in your transpiler. Ideally CJS modules
> >> >> > inside
> >> >> > projects written using ES6 modules should be treated as modules
> that
> >> >> > default
> >> >> > export an object. CJS modules don't have the same static semantics
> as
> >> >> > their
> >> >> > ES6 counterpart, so they should be treated as mutable objects. An
> ES6
> >> >> > Loader
> >> >> > would do the same when loading CJS modules.
> >> >> >
> >> >> > Juan
> >> >> ___
> >> >> es-discuss mailing list
> >> >> es-discuss@mo
Re: Re: Quantifying Default Exports
On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
wrote:
> that won't help if module.exports is a function
That's exactly what `minimist` is, works just fine.
https://github.com/substack/minimist/blob/master/index.js
>
> Overall the import/exports semantics of es6 and cjs modules would be
> compatible if mixing named and default exports was prohibited, but the
> ability to have both is hard to represent in cjs modules.
Don't understand this, do you have some code examples? I can't see why
that would be the case.
>
>
> On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma wrote:
>>
>> Which shows the how the backward compatability argument for default
>> export/imports doesn't stand up.
>>
>> If you want to import `module.exports` then use the the `module` form
>> if you want named imports use the named form.
>> Default import/exports are generating nothing more then complexity,
>> confusion and not serving their intended goals.
>>
>> On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
>> wrote:
>> > similar discussion at systemjs
>> > https://github.com/systemjs/systemjs/issues/131 which boils down to if a
>> > CJS
>> > module imports an ES6 module that has a key named default, what should
>> > the
>> > default behavior be.
>> >
>> >
>> > On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma
>> > wrote:
>> >>
>> >> It's using traceur and building the modules to CJS, the project uses
>> >> other non transpiled CJS modules.
>> >>
>> >> The only thing traceur could do here is compile the imports into a
>> >> check for the named export `default` and use that if it exists.
>> >> If it doesn't then simply return the CJS module object.
>> >>
>> >> Here is the output from traceur
>> >>
>> >>
>> >> https://github.com/briandipalma/global-compiler/blob/master/out/index.js
>> >>
>> >> The relevant line would be
>> >>
>> >> `var minimist = require('minimist');`
>> >>
>> >> For default import from a CJS module you'd need to output
>> >>
>> >> `
>> >> var minimist = require('minimist');
>> >> if (minimist.default) {
>> >> minimist = minimist.default;
>> >> }
>> >> `
>> >>
>> >> Is that what you think traceur should do?
>> >>
>> >> On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
>> >> wrote:
>> >> >
>> >> >> On Saturday, July 19, 2014 1:53 PM, Brian Di Palma
>> >> >>
>> >> >> wrote:
>> >> >
>> >> >> When an npm package exports a named identifier it's trivial to use
>> >> >> it
>> >> > in an ES6 module.
>> >> >
>> >> > import {
>> >> > parse,
>> >> > print
>> >> > } from 'recast';
>> >> >
>> >> >> When on the other hand it sets its export on `module.exports`
>> >> >> default
>> >> > exports provide no help at all.
>> >> >
>> >> > This sounds like an issue in your transpiler. Ideally CJS modules
>> >> > inside
>> >> > projects written using ES6 modules should be treated as modules that
>> >> > default
>> >> > export an object. CJS modules don't have the same static semantics as
>> >> > their
>> >> > ES6 counterpart, so they should be treated as mutable objects. An ES6
>> >> > Loader
>> >> > would do the same when loading CJS modules.
>> >> >
>> >> > Juan
>> >> ___
>> >> es-discuss mailing list
>> >> es-discuss@mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >
>> >
>> >
>> >
>> > --
>> > -Calvin W. Metcalf
>
>
>
>
> --
> -Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
that won't help if module.exports is a function
Overall the import/exports semantics of es6 and cjs modules would be
compatible if mixing named and default exports was prohibited, but the
ability to have both is hard to represent in cjs modules.
On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma wrote:
> Which shows the how the backward compatability argument for default
> export/imports doesn't stand up.
>
> If you want to import `module.exports` then use the the `module` form
> if you want named imports use the named form.
> Default import/exports are generating nothing more then complexity,
> confusion and not serving their intended goals.
>
> On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
> wrote:
> > similar discussion at systemjs
> > https://github.com/systemjs/systemjs/issues/131 which boils down to if
> a CJS
> > module imports an ES6 module that has a key named default, what should
> the
> > default behavior be.
> >
> >
> > On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma
> wrote:
> >>
> >> It's using traceur and building the modules to CJS, the project uses
> >> other non transpiled CJS modules.
> >>
> >> The only thing traceur could do here is compile the imports into a
> >> check for the named export `default` and use that if it exists.
> >> If it doesn't then simply return the CJS module object.
> >>
> >> Here is the output from traceur
> >>
> >>
> https://github.com/briandipalma/global-compiler/blob/master/out/index.js
> >>
> >> The relevant line would be
> >>
> >> `var minimist = require('minimist');`
> >>
> >> For default import from a CJS module you'd need to output
> >>
> >> `
> >> var minimist = require('minimist');
> >> if (minimist.default) {
> >> minimist = minimist.default;
> >> }
> >> `
> >>
> >> Is that what you think traceur should do?
> >>
> >> On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
> >> wrote:
> >> >
> >> >> On Saturday, July 19, 2014 1:53 PM, Brian Di Palma >
> >> >> wrote:
> >> >
> >> >> When an npm package exports a named identifier it's trivial to use it
> >> > in an ES6 module.
> >> >
> >> > import {
> >> > parse,
> >> > print
> >> > } from 'recast';
> >> >
> >> >> When on the other hand it sets its export on `module.exports` default
> >> > exports provide no help at all.
> >> >
> >> > This sounds like an issue in your transpiler. Ideally CJS modules
> inside
> >> > projects written using ES6 modules should be treated as modules that
> default
> >> > export an object. CJS modules don't have the same static semantics as
> their
> >> > ES6 counterpart, so they should be treated as mutable objects. An ES6
> Loader
> >> > would do the same when loading CJS modules.
> >> >
> >> > Juan
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> >
> > --
> > -Calvin W. Metcalf
>
--
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
Which shows the how the backward compatability argument for default
export/imports doesn't stand up.
If you want to import `module.exports` then use the the `module` form
if you want named imports use the named form.
Default import/exports are generating nothing more then complexity,
confusion and not serving their intended goals.
On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
wrote:
> similar discussion at systemjs
> https://github.com/systemjs/systemjs/issues/131 which boils down to if a CJS
> module imports an ES6 module that has a key named default, what should the
> default behavior be.
>
>
> On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma wrote:
>>
>> It's using traceur and building the modules to CJS, the project uses
>> other non transpiled CJS modules.
>>
>> The only thing traceur could do here is compile the imports into a
>> check for the named export `default` and use that if it exists.
>> If it doesn't then simply return the CJS module object.
>>
>> Here is the output from traceur
>>
>> https://github.com/briandipalma/global-compiler/blob/master/out/index.js
>>
>> The relevant line would be
>>
>> `var minimist = require('minimist');`
>>
>> For default import from a CJS module you'd need to output
>>
>> `
>> var minimist = require('minimist');
>> if (minimist.default) {
>> minimist = minimist.default;
>> }
>> `
>>
>> Is that what you think traceur should do?
>>
>> On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
>> wrote:
>> >
>> >> On Saturday, July 19, 2014 1:53 PM, Brian Di Palma
>> >> wrote:
>> >
>> >> When an npm package exports a named identifier it's trivial to use it
>> > in an ES6 module.
>> >
>> > import {
>> > parse,
>> > print
>> > } from 'recast';
>> >
>> >> When on the other hand it sets its export on `module.exports` default
>> > exports provide no help at all.
>> >
>> > This sounds like an issue in your transpiler. Ideally CJS modules inside
>> > projects written using ES6 modules should be treated as modules that
>> > default
>> > export an object. CJS modules don't have the same static semantics as their
>> > ES6 counterpart, so they should be treated as mutable objects. An ES6
>> > Loader
>> > would do the same when loading CJS modules.
>> >
>> > Juan
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> -Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils down to if a
CJS module imports an ES6 module that has a key named default, what should
the default behavior be.
On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma wrote:
> It's using traceur and building the modules to CJS, the project uses
> other non transpiled CJS modules.
>
> The only thing traceur could do here is compile the imports into a
> check for the named export `default` and use that if it exists.
> If it doesn't then simply return the CJS module object.
>
> Here is the output from traceur
>
> https://github.com/briandipalma/global-compiler/blob/master/out/index.js
>
> The relevant line would be
>
> `var minimist = require('minimist');`
>
> For default import from a CJS module you'd need to output
>
> `
> var minimist = require('minimist');
> if (minimist.default) {
> minimist = minimist.default;
> }
> `
>
> Is that what you think traceur should do?
>
> On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
> wrote:
> >
> >> On Saturday, July 19, 2014 1:53 PM, Brian Di Palma
> wrote:
> >
> >> When an npm package exports a named identifier it's trivial to use it
> > in an ES6 module.
> >
> > import {
> > parse,
> > print
> > } from 'recast';
> >
> >> When on the other hand it sets its export on `module.exports` default
> > exports provide no help at all.
> >
> > This sounds like an issue in your transpiler. Ideally CJS modules inside
> projects written using ES6 modules should be treated as modules that
> default export an object. CJS modules don't have the same static semantics
> as their ES6 counterpart, so they should be treated as mutable objects. An
> ES6 Loader would do the same when loading CJS modules.
> >
> > Juan
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
It's using traceur and building the modules to CJS, the project uses
other non transpiled CJS modules.
The only thing traceur could do here is compile the imports into a
check for the named export `default` and use that if it exists.
If it doesn't then simply return the CJS module object.
Here is the output from traceur
https://github.com/briandipalma/global-compiler/blob/master/out/index.js
The relevant line would be
`var minimist = require('minimist');`
For default import from a CJS module you'd need to output
`
var minimist = require('minimist');
if (minimist.default) {
minimist = minimist.default;
}
`
Is that what you think traceur should do?
On Mon, Jul 21, 2014 at 2:34 PM, Juan Ignacio Dopazo
wrote:
>
>> On Saturday, July 19, 2014 1:53 PM, Brian Di Palma wrote:
>
>> When an npm package exports a named identifier it's trivial to use it
> in an ES6 module.
>
> import {
> parse,
> print
> } from 'recast';
>
>> When on the other hand it sets its export on `module.exports` default
> exports provide no help at all.
>
> This sounds like an issue in your transpiler. Ideally CJS modules inside
> projects written using ES6 modules should be treated as modules that default
> export an object. CJS modules don't have the same static semantics as their
> ES6 counterpart, so they should be treated as mutable objects. An ES6 Loader
> would do the same when loading CJS modules.
>
> Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
> On Saturday, July 19, 2014 1:53 PM, Brian Di Palma wrote:
> When an npm package exports a named identifier it's trivial to use it
in an ES6 module.
import {
parse,
print
} from 'recast';
> When on the other hand it sets its export on `module.exports` default
exports provide no help at all.
This sounds like an issue in your transpiler. Ideally CJS modules inside
projects written using ES6 modules should be treated as modules that default
export an object. CJS modules don't have the same static semantics as their ES6
counterpart, so they should be treated as mutable objects. An ES6 Loader would
do the same when loading CJS modules.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Quantifying Default Exports
Great work on the analysis, very thorough.
For what it's worth I disagree with
3) Default exports improve interoperability with legacy modules.
Based on my experience default exports do not help interoperability
with legacy module systems.
I'm currently working on a global namespaced script code to ES6/CJS
module compiler using node.js.
The compiler is written in ES6 and I'm using CJS npm packages in the project.
When an npm package exports a named identifier it's trivial to use it
in an ES6 module.
import {
parse,
print
} from 'recast';
When on the other hand it sets its export on `module.exports` default
exports provide no help at all.
There is no export named `default` to import, so I'm forced to use the
module form.
module minimist from 'minimist';
Examples taken from
https://github.com/briandipalma/global-compiler/blob/master/src/index.js
Default imports/exports seem totally unnecessary to me.
Nothing more then a distraction, providing no value but overhead.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
