How to fix this ES6 module circular dependency?

Question

EDIT: for more background, also see the discussion on ES Discuss.

---

I have three modules A, B, and C. A and B import the default export from module C, and module C imports the default from both A and B. However, module C does not depend on the values imported from A and B during module evaluation, only at runtime at some point after all three modules have been evaluated. Modules A and B do depend on the value imported from C during their module evaluation.

The code looks something like this:

// --- Module A  import C from 'C'  class A extends C {     // ... }  export {A as default} 

.

// --- Module B  import C from 'C'  class B extends C {     // ... }  export {B as default} 

.

// --- Module C  import A from 'A' import B from 'B'  class C {     constructor() {         // this may run later, after all three modules are evaluated, or         // possibly never.         console.log(A)         console.log(B)     } }  export {C as default} 

I have the following entry point:

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

But, what actually happens is that module B is evaluated first, and it fails with this error in Chrome (using native ES6 classes, not transpiling):

Uncaught TypeError: Class extends value undefined is not a function or null 

What that means is that the value of C in module B when module B is being evaluated is undefined because module C has not yet been evaluated.

You should be able to easily reproduce by making those four files, and running the entrypoint file.

My questions are (can I have two concrete questions?): Why is the load order that way? How can the circularly-dependent modules be written so that they will work so that the value of C when evaluating A and B will not be undefined?

(I would think that the ES6 Module environment may be able to intelligently discover that it will need to execute the body of module C before it can possibly execute the bodies of modules A and B.)

Answer 1

The answer is to use "init functions". For reference, look at the two messages starting here: https://esdiscuss.org/topic/how-to-solve-this-basic-es6-module-circular-dependency-problem#content-21

The solution looks like this:

// --- Module A  import C, {initC} from './c';  initC();  console.log('Module A', C)  class A extends C {     // ... }  export {A as default} 

-

// --- Module B  import C, {initC} from './c';  initC();  console.log('Module B', C)  class B extends C {     // ... }  export {B as default} 

-

// --- Module C  import A from './a' import B from './b'  var C;  export function initC(){     if (C) return;      C = class C {         constructor() {             console.log(A)             console.log(B)         }     } }  initC();  export {C as default}; // IMPORTANT: not `export default C;` !! 

-

// --- Entrypoint  import A from './A' console.log('Entrypoint', new A) // runs the console.logs in the C constructor. 

Also see this thread for related info: https://github.com/meteor/meteor/issues/7621#issuecomment-238992688

It is important to note that exports are hoisted (it may be strange, you can ask in esdiscuss to learn more) just like var, but the hoisting happens across modules. Classes cannot be hoisted, but functions can be (just like they are in normal pre-ES6 scopes, but across modules because exports are live bindings that reach into other modules possibly before they are evaluated, almost as if there is a scope that encompasses all modules where identifiers can be accessed only through the use of import).

In this example, the entry point imports from module A, which imports from module C, which imports from module B. This means module B will be evaluated before module C, but due to the fact that the exported initC function from module C is hoisted, module B will be given a reference to this hoisted initC function, and therefore module B call call initC before module C is evaluated.

This causes the var C variable of module C to become defined prior to the class B extends C definition. Magic!

It is important to note that module C must use var C, not const or let, otherwise a temporal deadzone error should theoretically be thrown in a true ES6 environment. For example, if module C looked like

// --- Module C  import A from './a' import B from './b'  let C;  export function initC(){     if (C) return;      C = class C {         constructor() {             console.log(A)             console.log(B)         }     } }  initC();  export {C as default}; // IMPORTANT: not `export default C;` !! 

then as soon as module B calls initC, an error will be thrown, and the module evaluation will fail.

var is hoisted within the scope of module C, so it is available for when initC is called. This is a great example of a reason why you'd actually want to use var instead of let or const in an ES6+ environment.

However, you can take note rollup doesn't handle this correctly https://github.com/rollup/rollup/issues/845, and a hack that looks like let C = C can be used in some environments like pointed out in the above link to the Meteor issue.

One last important thing to note is the difference between export default C and export {C as default}. The first version does not export the C variable from module C as a live binding, but by value. So, when export default C is used, the value of var C is undefined and will be assigned onto a new variable var default that is hidden inside the ES6 module scope, and due to the fact that C is assigned onto default (as in var default = C by value, then whenever the default export of module C is accessed by another module (for example module B) the other module will be reaching into module C and accessing the value of the default variable which is always going to be undefined. So if module C uses export default C, then even if module B calls initC (which does change the values of module C's internal C variable), module B won't actually be accessing that internal C variable, it will be accessing the default variable, which is still undefined.

However, when module C uses the form export {C as default}, the ES6 module system uses the C variable as the default exported variable rather than making a new internal default variable. This means that the C variable is a live binding. Any time a module depending on module C is evaluated, it will be given the module C's internal C variable at that given moment, not by value, but almost like handing over the variable to the other module. So, when module B calls initC, module C's internal C variable gets modified, and module B is able to use it because it has a reference to the same variable (even if the local identifier is different)! Basically, any time during module evaluation, when a module will use the identifier that it imported from another module, the module system reaches into the other module and gets the value at that moment in time.

I bet most people won't know the difference between export default C and export {C as default}, and in many cases they won't need to, but it is important to know the difference when using "live bindings" across modules with "init functions" in order to solve circular dependencies, among other things where live bindings can be useful. Not to delve too far off topic, but if you have a singleton, alive bindings can be used as a way to make a module scope be the singleton object, and live bindings the way in which things from the singleton are accessed.

One way to describe what is happening with the live bindings is to write javascript that would behave similar to the above module example. Here's what modules B and C might look like in a way that describes the "live bindings":

// --- Module B  initC()  console.log('Module B', C)  class B extends C {     // ... }  // --- Module C  var C  function initC() {     if (C) return      C = class C {         constructor() {             console.log(A)             console.log(B)         }     } }  initC() 

This shows effectively what is happening in in the ES6 module version: B is evaluated first, but var C and function initC are hoisted across the modules, so module B is able to call initC and then use C right away, before var C and function initC are encountered in the evaluated code.

Of course, it gets more complicated when modules use differing identifiers, for example if module B has import Blah from './c', then Blah will still be a live binding to the C variable of module C, but this is not very easy to describe using normal variable hoisting as in the previous example, and in fact Rollup isn't always handling it properly.

Suppose for example we have module B as the following and modules A and C are the same:

// --- Module B  import Blah, {initC} from './c';  initC();  console.log('Module B', Blah)  class B extends Blah {     // ... }  export {B as default} 

Then if we use plain JavaScript to describe only what happens with modules B and C, the result would be like this:

// --- Module B  initC()  console.log('Module B', Blah)  class B extends Blah {     // ... }  // --- Module C  var C var Blah // needs to be added  function initC() {     if (C) return      C = class C {         constructor() {             console.log(A)             console.log(B)         }     }     Blah = C // needs to be added }  initC() 

Another thing to note is that module C also has the initC function call. This is just in case module C is ever evaluated first, it won't hurt to initialize it then.

And the last thing to note is that in these example, modules A and B depend on C at module evaluation time, not at runtime. When modules A and B are evaluated, then require for the C export to be defined. However, when module C is evaluated, it does not depend on A and B imports being defined. Module C will only need to use A and B at runtime in the future, after all modules are evaluated, for example when the entry point runs new A() which will run the C constructor. It is for this reason that module C does not need initA or initB functions.

It is possible that more than one module in a circular dependency need to depend on each other, and in this case a more complex "init function" solution is needed. For example, suppose module C wants to console.log(A) during module evaluation time before class C is defined:

// --- Module C  import A from './a' import B from './b'  var C;  console.log(A)  export function initC(){     if (C) return;      C = class C {         constructor() {             console.log(A)             console.log(B)         }     } }  initC();  export {C as default}; // IMPORTANT: not `export default C;` !! 

Due to the fact that the entry point in the top example imports A, the C module will be evaluated before the A module. This means that console.log(A) statement at the top of module C will log undefined because class A hasn't been defined yet.

Finally, to make the new example work so that it logs class A instead of undefined, the whole example becomes even more complicated (I've left out module B and the entry point, since those don't change):

// --- Module A  import C, {initC} from './c';  initC();  console.log('Module A', C)  var A  export function initA() {     if (A) return      initC()      A = class A extends C {         // ...     } }  initA()  export {A as default} // IMPORTANT: not `export default A;` !! 

-

// --- Module C  import A, {initA} from './a' import B from './b'  initA()  var C;  console.log(A) // class A, not undefined!  export function initC(){     if (C) return;      C = class C {         constructor() {             console.log(A)             console.log(B)         }     } }  initC();  export {C as default}; // IMPORTANT: not `export default C;` !! 

Now, if module B wanted to use A during evaluation time, things would get even more complicated, but I leave that solution for you to imagine...