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
