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 <guybedf...@gmail.com> 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 <johnjbar...@google.com> wrote: >> >> >> >> >> 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