Actually, Babel defers circular dependencies to the underlying module
resolver, so most likely Node/Browserify/etc. is where you're getting that,
as that's actually intentional, documented behavior in Node.
On Wed, Dec 23, 2015, 20:24 /#!/JoePea wrote:
> Cool, thanks guys. Indeed that appears to
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
> issue is, but this isn't re
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
to
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
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 logic for A and B in
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 pac
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 w
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
On Fri, Mar 14, 2014 at 3:34 PM, John Barton wrote:
> On Fri, Mar 14, 2014 at 11:42 AM, David Herman wrote:
>> When you export from a module, you're exporting bindings, rather than
>> values. This means you can refactor between
>>
>> module m from "foo";
>> ...
>> m.bar
>>
>> and
>>
>
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 t
xports
> during initialization, you don't run into as many subtle
> order-of-initialization issues as you do with AMD and Node, because
> importing something syntactically early doesn't mean you accidentally
> snapshot its pre-initialized state.
>
> (Also, keep in mind th
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:
I agree with the confusion (due in part because the
>
>
> ExportDeclaration :
> ...
> export default FunctionDeclaration ;
> export default ClassDeclaration ;
> export default [lookahead !in { function, class }]
> AssignmentExpression ;
>
I think this would allay most of my concerns.
_
From: es-discuss on behalf of David Herman
> 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 rules so that function and class declarations sco
On Mar 14, 2014, at 10:50 AM, Russell Leggett 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
major syntax redesign at this
>
>
> Functions with return AssignmentExpression that include "=" and
> without--are the ones without also confusing without the "necessary" visual
> cue?
>
No, because they are preceded by keywords that also indicate an expression
context, in this case "return" and "yield".
__
On Mar 14, 2014, at 9:37 AM, Andrea Giammarchi
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 up with weak analogies. The
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.)
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
>
>
>> 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 surpr
On Fri, Mar 14, 2014 at 12:24 PM, Kevin Smith 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,
;> // module3.js
>> module module1 from "./module1";
>> let { foo, changeFoo } = module1;
>>
>> // Destructuring uses assignment to copy over the current values
>> // So calling changeFoo does not affect this binding for foo
>>
>> console.log(
s
> // So calling changeFoo does not affect this binding for foo
>
> console.log(foo); // 5
> changeFoo();
> console.log(foo); // 5
>
>
>
>
>
> From: John Barton
> Sent: Friday, March 14, 2014 10:35
> To: Domenic Denicola
> Cc: Mark Volkmann; Kevin Smith; es-di
>
>
> 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
On Fri, Mar 14, 2014 at 9:15 AM, Rick Waldron wrote:
>
>
>
> On Fri, Mar 14, 2014 at 11:04 AM, Kevin Smith wrote:
>
>>
>>>
>>> Because it doesn't allow for the Assignment Expression form
>>> (specifically, function expressions) that developers expect to be able to
>>> write:
>>>
>>> export defau
On Fri, Mar 14, 2014 at 11:04 AM, Kevin Smith 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 MyT
Sigh. The example just better demonstrates how clunky the syntax is
and how surprising the semantics can be. :(
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 Second Sys
>
>
>
> 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, m
Indeed. If you have used Node.js extensively, I am sure you are familiar with
this paradigm.
From: es-discuss on behalf of Mark Volkmann
Sent: Friday, March 14, 2014 10:50
To: Rick Waldron
Cc: es-discuss@mozilla.org
Subject: Re: module exports
Is the common
ow 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:
>>>
>&
On Fri, Mar 14, 2014 at 10:07 AM, Mark Volkmann
wrote:
> On Fri, Mar 14, 2014 at 8:54 AM, Kevin Smith wrote:
>
>>
>>> 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 imp
nsole.log(foo); // 5
From: John Barton
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
wrote:
Importing
t syntax is used for
> each case.
>
> --
> *From:* Mark Volkmann
> *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 aft
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
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';
instea
>
> export { foo as default };
>>
>> I fail to see why sugar over this form is necessary.
>>
>
> I completely agree. Plus if this is taken away then the "import" keyword
> can be used to get the whole module as in my example above. At that point
> maybe there is no need for the "module" keyword
On Fri, Mar 14, 2014 at 8:54 AM, Kevin Smith wrote:
>
>> 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 im
>
>
>
> 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 ob
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
le,
> export {name1, name2, ...};
>
> Here's 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 mod
of what a given 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 thing
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 Kasr
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, David
> 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
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, wha
44 matches
Mail list logo
