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 <j...@trusktr.io> wrote:
> Cool, thanks guys. Indeed that appears to have been my problem.
>
> On Tue, Dec 22, 2015 at 10:59 PM, Logan Smyth <loganfsm...@gmail.com>
> 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 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 take a look, so feel free to ping me.
> >
> > On Tue, Dec 22, 2015 at 5:49 PM, Caridy Patino <car...@gmail.com> wrote:
> >>
> >> 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 experiencing. as for the {}, that's just
> >> babel.
> >>
> >> side note: this has nothing to do with those being default exports, it
> >> will happen for any export.
> >>
> >> /caridy
> >>
> >> > On Dec 21, 2015, at 10:25 PM, /#!/JoePea <j...@trusktr.io> wrote:
> >> >
> >> > 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
> >> > import B from './B'
> >> > let A = window.globalThing
> >> > export default A
> >> >
> >> > // modify the A object adding methods that reference B.
> >> > ```
> >> >
> >> > ```js
> >> > // B.js
> >> > import A from './A'
> >> > let B = new window.OtherThing
> >> > export default B
> >> >
> >> > console.log(A) // an empty object, {}
> >> >
> >> > // modify the B object which depends on A existing (not being some
> >> > temporary
> >> > // object like I get with Webpack) while the module is evaluated.
> >> > ```
> >> >
> >> > When using Webpack, this code fails because the reference to A in B is
> >> > some empty object. If I import both A and B into main.js, then A is
> >> > defined as epected:
> >> >
> >> > ```js
> >> > // main.js
> >> > import A from './A'
> >> > import B from './B'
> >> >
> >> > console.log(A) // An object with a bunch of properties, as expected.
> >> > ```
> >> >
> >> > I can fix my problem by exporting functions to do setup of A and B,
> >> > and running those functions in main.js, like this:
> >> >
> >> > ```js
> >> > // A.js
> >> > import B from './B'
> >> > let A = window.globalThing
> >> > export default A
> >> >
> >> > A.setup = () => {
> >> > // modify the A object adding methods that reference B.
> >> > }
> >> > ```
> >> >
> >> > ```js
> >> > // B.js
> >> > import A from './A'
> >> > let B = new window.OtherThing
> >> > export default B
> >> >
> >> > console.log(A) // an empty object, {}
> >> >
> >> > B.setup = () => {
> >> > console.log(A) // the expected object!! Why?
> >> >
> >> > // modify the B object which depends on A existing (not being some
> >> > temporary
> >> > // object like I get with Webpack) while the module is evaluated.
> >> > }
> >> > ```
> >> >
> >> > When using Webpack, this code fails because the reference to A in B is
> >> > just `{}`, some empty object. If I import both A and B into main.js,
> >> > then A is defined as epected:
> >> >
> >> > ```js
> >> > // main.js
> >> > import A from './A'
> >> > import B from './B'
> >> >
> >> > A.setup()
> >> > B.setup()
> >> >
> >> > // no more problems!
> >> >
> >> > console.log(A) // An object with a bunch of properties, as expected.
> >> > ```
> >> >
> >> > So, if I run the setup for A and B in main.js instead of in the module
> >> > evaluation, everything works perfectly.
> >> >
> >> > This led me to wonder: What is the expected behavior of circular
> >> > dependencies in ES2015? Have you had this 'empty object' problem
> >> > before? Is that expected to happen, or might there be a bug in
> >> > Webpack?
> >> >
> >> > I guess the problem makes sense: How can the first method (running
> >> > relying on module evaluation for setting up A and B exports) work if
> >> > module B depends on the evaluation of module A which depends on the
> >> > evaluation of module B?
> >> > _______________________________________________
> >> > 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
