Re: Modifying ES6 module exports

Cool, thanks guys. Indeed that appears to have been my problem. On Tue, Dec 22, 2015 at 10:59 PM, Logan Smyth wrote: > The `{}` shouldn't be from Babel, it has handled all circular dependency > cases as far as I'm aware. I'm curious to know what the end cause of this >

Re: Modifying ES6 module exports

circular dependencies will work nicely with declarations, not so much with expressions because the code has to be evaluated to set those bindings. This, of course, is not a problem if you're not invoking some initialization when evaluating the body of the module. all in all, that's what you're

Re: Modifying ES6 module exports

The `{}` shouldn't be from Babel, it has handled all circular dependency cases as far as I'm aware. I'm curious to know what the end cause of this issue is, but this isn't really the right discussion forum for it. Joe, if you do end up making a simplified example that can be tested, I'd be happy

Re: Modifying ES6 module exports

In my case I was using Webpack+babel-loader. I guess that makes sense, about the run-time dependencies. After solving the problem by wrapping the module logic for A and B in functions then calling those functions in main.js. I then encountered another problem: package C imports the default from

Re: Modifying ES6 module exports

Related: http://www.2ality.com/2015/07/es6-module-exports.html?m=1 On Tue, Dec 22, 2015 at 4:02 AM /#!/JoePea wrote: > In my case I was using Webpack+babel-loader. I guess that makes sense, > about the run-time dependencies. After solving the problem by wrapping > the module

Re: Modifying ES6 module exports

To start, an object is definitely not what I'd expect. The core thing to remember with ES6 modules is that while imports are live bindings, you still need to write your code in such a way that it has no run-time circular dependencies. In your specific examples, you are importing `A` first, which

Modifying ES6 module exports

I'm curious, what should happen when module A imports the default from module B which imports the default from module A? Should the exported A object exist inside of module B? Here's two modules A and B (simplified from some real code that I have), which have a circular dependency: ```js // A.js

module exports

module exports that it identified as the default (presumably the most commonly used things) To define the default subset of things to export from a module, export default = some-value or some-function; where some-value could be an object holding a collection of things to export. -- R. Mark

Re: module exports

the part that confuses me most. It seems that importers have three options. 1) import specific things from a given module 2) import everything that was exported from a given module 3) import a subset of what a given module exports that it identified as the default (presumably the most commonly used

Re: module exports

I have used Node.js extensively. In that environment, as I'm sure you know, a module exports one thing. It can be an object with lots of properties on it, a single function, or a single value. I suppose you could say that all Node has is a default export which is the one thing the module exports

Re: module exports

I'm trying to understand how that compares to ES6 modules. I see how in ES6 I can import specific things from a module or I can import everything a module exports. You can't really import all exported bindings. You can import the module instance object itself: module M from wherever

Re: module exports

I understand it's hard to make changes after a certain point. It's too bad though that developers will have to remember that the way to import a few things from a module is: import {foo, bar} from 'somewhere'; but the way to import the whole module is: module SomeModule from 'somewhere';

RE: module exports

Denicola; es-discuss@mozilla.org Subject: Re: module exports I understand it's hard to make changes after a certain point. It's too bad though that developers will have to remember that the way to import a few things from a module is: import {foo, bar} from 'somewhere'; but the way to import

Re: module exports

. -- *From:* Mark Volkmann r.mark.volkm...@gmail.com *Sent:* Friday, March 14, 2014 10:19 *To:* Kevin Smith *Cc:* Domenic Denicola; es-discuss@mozilla.org *Subject:* Re: module exports I understand it's hard to make changes after a certain point. It's too bad though that developers

RE: module exports

From: John Barton johnjbar...@google.com Sent: Friday, March 14, 2014 10:35 To: Domenic Denicola Cc: Mark Volkmann; Kevin Smith; es-discuss@mozilla.org Subject: Re: module exports   What is a 'mutable binding'? On Fri, Mar 14, 2014 at 7:30 AM, Domenic Denicola dome...@domenicdenicola.com wrote

Re: module exports

everything a module exports. You can't really import all exported bindings. You can import the module instance object itself: module M from wherever; which will give you access to all of the exports. That's what I meant by importing all the exports. I'd prefer it if the syntax

Re: module exports

a module or I can import everything a module exports. You can't really import all exported bindings. You can import the module instance object itself: module M from wherever; which will give you access to all of the exports. That's what I meant by importing all the exports. I'd

RE: module exports

@mozilla.org Subject: Re: module exports Is the common use case for export default when you want to give users of the module an easy way to obtain a single function? So instead of users doing this: import {someFn} from 'wherever'; they can do this: import someFn from 'wherever'; On Fri, Mar

Re: module exports

Because it doesn't allow for the Assignment Expression form (specifically, function expressions) that developers expect to be able to write: export default function() {} The alternative here is: function MyThing() {} export { MyThing as default }; Which is more clear, more

Re: module exports

Sigh. The example just better demonstrates how clunky the syntax is and how surprising the semantics can be. :( rant I hope one of the CommonJS or RequireJS folks write a good ES6 module loader so that I can continue to use reasonable syntax and ignore all of this. This really smells like

Re: module exports

On Fri, Mar 14, 2014 at 11:04 AM, Kevin Smith zenpars...@gmail.com wrote: Because it doesn't allow for the Assignment Expression form (specifically, function expressions) that developers expect to be able to write: export default function() {} The alternative here is: function

Re: module exports

On Fri, Mar 14, 2014 at 9:15 AM, Rick Waldron waldron.r...@gmail.comwrote: On Fri, Mar 14, 2014 at 11:04 AM, Kevin Smith zenpars...@gmail.comwrote: Because it doesn't allow for the Assignment Expression form (specifically, function expressions) that developers expect to be able to

Re: module exports

var f = function a() {}; a(); // nope. Sure, note the equals (which is my point). var D = class C {}; And no one would expect to be able to this: var c = new C(); Same thing. Note the equals, which gives the reader the necessary visual cue that we are entering an

Re: module exports

: John Barton johnjbar...@google.com Sent: Friday, March 14, 2014 10:35 To: Domenic Denicola Cc: Mark Volkmann; Kevin Smith; es-discuss@mozilla.org Subject: Re: module exports What is a 'mutable binding'? On Fri, Mar 14, 2014 at 7:30 AM, Domenic Denicola dome...@domenicdenicola.com wrote

Re: module exports

On Fri, Mar 14, 2014 at 12:24 PM, Kevin Smith zenpars...@gmail.com wrote: var f = function a() {}; a(); // nope. Sure, note the equals (which is my point). var D = class C {}; And no one would expect to be able to this: var c = new C(); Same thing. Note the equals, which

Re: module exports

I don't understand this claim, any legal AssignmentExpression form is allowed. I've said this before, but without the equals it looks too much like a declaration: export default class C {} var c = new C(); // No C defined, WTF? Why is this surprising? It is surprising

Re: module exports

-initialized state. (Also, keep in mind that the vast majority of module exports are set once and never changed, in which case this semantics *only* fixes bugs.) Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: module exports

On Mar 14, 2014, at 9:37 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I like that more I read about this, more the `with` statement comes into my mind ... There's nothing like this in JS today, so if you're only looking for precedent there, you're only going to be able to come

Re: module exports

On Mar 14, 2014, at 10:50 AM, Russell Leggett russell.legg...@gmail.com wrote: I completely agree with this. It looks like a modifier. This is a good point, and folks working on the Square transpiler noticed this, too. I think there's a more surgical fix, though (and I'm not entertaining

RE: module exports

From: es-discuss es-discuss-boun...@mozilla.org on behalf of David Herman dher...@mozilla.com So I think we should consider doing the same thing as we do for ExpressionStatement: ... This actually results in no net change to the language syntax, but it allows us to change the scoping

Re: module exports

ExportDeclaration : ... export default FunctionDeclaration ; export default ClassDeclaration ; export default [lookahead !in { function, class }] AssignmentExpression ; I think this would allay most of my concerns.

RE: module exports

David Herman wrote: I think we're seeing the exact same phenomenon with `export default` -- the modifiers make it look more like a declaration context. So I think we should consider doing the same thing as we do for ExpressionStatement: snip I agree with the confusion (due in part because

Re: module exports

do with AMD and Node, because importing something syntactically early doesn't mean you accidentally snapshot its pre-initialized state. (Also, keep in mind that the vast majority of module exports are set once and never changed, in which case this semantics *only* fixes bugs.) If I am

Re: module exports

David I know the analogy was weak but since indeed you said there's nothing like that, I named the one that felt somehow close because of some implicit behavior. I am personally easy going on modules, I like node.js require and I think that behind an await like approach could work asynchronously

Re: module exports

On Fri, Mar 14, 2014 at 3:34 PM, John Barton johnjbar...@google.com wrote: On Fri, Mar 14, 2014 at 11:42 AM, David Herman dher...@mozilla.com wrote: When you export from a module, you're exporting bindings, rather than values. This means you can refactor between module m from foo;

Re: module exports

Yes, thanks, my mistake on the unexported startCar function declaration. My question is more about semantics, if the author of engine did not want to export start, the grammar allows anyone importing the engine module to override the original author's intent. On Jul 10, 2011, at 8:11 PM,

Re: module exports

No, a module determines its exports by itself, and no one can override that. Notice that you missed *two* export declarations, car.startCar *and* car.engine.start. If the engine module doesn't export start, then the outer car module cannot access it. Dave On Jul 10, 2011, at 11:19 PM, Kam

module exports

Hi Dave: According to the module grammar, the following is valid: 691module car { function startCar() {} module engine { function start() {} } export {start:startCar} from engine; } It seems like there would be issues with exporting module elements after the module has been defined. Also,

Re: module exports

According to the module grammar, the following is valid: 691module car { function startCar() {} module engine { function start() {} } export {start:startCar} from engine; } It seems like there would be issues with exporting module elements after the module has been