On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford <guybedf...@gmail.com> 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 <car...@gmail.com> 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 <off...@gmail.com>
>> 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
>>> <calvin.metc...@gmail.com> 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
>>> >> <calvin.metc...@gmail.com> 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 <off...@gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
>>> >> >> <calvin.metc...@gmail.com> 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 <
>>> off...@gmail.com>
>>> >> >> > 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
>>> >> >> >> <calvin.metc...@gmail.com> 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
>>> >> >> >> > <off...@gmail.com>
>>> >> >> >> > 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
>>> >> >> >> >> <jdop...@yahoo-inc.com> wrote:
>>> >> >> >> >> >
>>> >> >> >> >> >> On Saturday, July 19, 2014 1:53 PM, Brian Di Palma
>>> >> >> >> >> >> <off...@gmail.com>
>>> >> >> >> >> >> 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
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > -Calvin W. Metcalf
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > -Calvin W. Metcalf
>>> _______________________________________________
>>> 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
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
