How to solve this basic ES6-module circular dependency problem?

/#!/JoePea joe at
Wed Aug 10 04:59:49 UTC 2016

It seems that the environment I'm in (Meteor uses [reify]( tries to evaluate A and B first, so I
thought I could take advantage of "live bindings" by changing my modules to
the following:

// --- Entrypoint

import A from './app/A'
console.log('Entrypoint', A)

// --- Module A

import C from './C'

let A

function setUpA() {


    A = class A extends C {
        // ...


console.log('Module A', C, setUpA)

export {A as default}

// --- Module B

import C from './C'

let B

function setUpB() {

    console.log('setUpB', C)

    B = class B extends C {
        // ...


console.log('Module B', C, setUpB)

export {B as default}

// --- Module C

import A, {setUpA} from './A'
import B, {setUpB} from './B'

let C = class C {
    constructor() {
        // this may run later, after all three modules are evaluated, or
        // possibly never.

console.log('Module C', A)

console.log('Module C', B)

export {C as default}

As you can see, modules A and B simply export the code that should be
evaluated (note the live bindings). Then finally, the C module is evaluated
last. At the end of the C module, you see that it calls `setUpA` and
`setUpB`. When it fires `setUpA`, an error is thrown on the second
`console.log` that `C` is undefined (or, specifically, `C.default` is
`undefined` because the ES6 modules are compiled into CommonJS form).

I thought that if `C` was a live binding, then it should be ready by the
time the `setUpA` function is called. Should this in fact be the case?


On Tue, Aug 9, 2016 at 5:36 PM, John Lenz <concavelenz at> wrote:

> Without a way to load "later" (aka "soft") dependencies, ES6 module will
> continue to be more or less broken for circular dependencies.
> On Tue, Aug 9, 2016 at 4:11 PM, Tab Atkins Jr. <jackalmage at>
> wrote:
>> On Tue, Aug 9, 2016 at 4:00 PM, /#!/JoePea <joe at> wrote:
>> > True, and so that's why I'm wondering if the module system can see that
>> it
>> > can satisfy all module requirements if it simply evaluates module C
>> first,
>> > followed by A or B in any order. It is easy for us humans to see that.
>> It
>> > would be nice for the module system to see that as well (I'm not sure if
>> > that is spec'd or not).
>> That knowledge requires, at minimum, evaluating the rest of each
>> module, beyond what is expressed in the `import` statements.  That's
>> assuming there's no dynamic trickery going on that would invalidate
>> whatever assumptions it can draw from surface-level analysis.
>> Because of this, only the `import` statements are declaratively
>> available to the module system to work with.  Based on that, it
>> definitely can't make any ordering assumptions; all it knows is that A
>> imports C, B imports C, and C imports both A and B, making a circular
>> import.
>> ~TJ
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list