Hi Calvin,
On 21 juil. 2014, at 17:16, Calvin Metcalf
calvin.metc...@gmail.commailto: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
On 22 Jul 2014 00:30, Calvin Metcalf calvin.metc...@gmail.com 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
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
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 =
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
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
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
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
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
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
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
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
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
(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,
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
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
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
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
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
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({
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 off...@gmail.com wrote:
It
Wasn't the original issue single exports and their demonstrated utility in
node and AMD?
On Jul 21, 2014 5:49 PM, John Barton johnjbar...@google.com wrote:
There are two issues here:
1) Is 'default' essential?
2) Should the spec. explicitly define commonjs loading?
Brian is claiming 1)
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
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
24 matches
Mail list logo
