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...

Answer 2

I would recommend to use inversion of control. Make your C constructor pure by adding an A and a B parameter like this:

// --- Module A

import C from './C';

export default class A extends C {
    // ...
}

// --- Module B

import C from './C'

export default class B extends C {
    // ...
}

// --- Module C

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

// --- Entrypoint

import A from './A';
import B from './B';
import C from './C';
const c = new C(A, B);
console.log('Entrypoint', C, c);
document.getElementById('out').textContent = 'Entrypoint ' + C + ' ' + c;

https://www.webpackbin.com/bins/-KlDeP9Rb60MehsCMa8u

Update, in response to this comment: How to fix this ES6 module circular dependency?

Alternatively, if you do not want the library consumer to know about various implementations, you can either export another function/class that hides those details:

// Module ConcreteCImplementation
import A from './A';
import B from './B';
import C from './C';
export default function () { return new C(A, B); }

or use this pattern:

// --- Module A

import C, { registerA } from "./C";

export default class A extends C {
  // ...
}

registerA(A);

// --- Module B

import C, { registerB } from "./C";

export default class B extends C {
  // ...
}

registerB(B);

// --- Module C

let A, B;

const inheritors = [];

export const registerInheritor = inheritor => inheritors.push(inheritor);

export const registerA = inheritor => {
  registerInheritor(inheritor);
  A = inheritor;
};

export const registerB = inheritor => {
  registerInheritor(inheritor);
  B = inheritor;
};

export default class C {
  constructor() {
    // this may run later, after all three modules are evaluated, or
    // possibly never.
    console.log(A);
    console.log(B);
    console.log(inheritors);
  }
}

// --- Entrypoint

import A from "./A";
import B from "./B";
import C from "./C";
const c = new C();
console.log("Entrypoint", C, c);
document.getElementById("out").textContent = "Entrypoint " + C + " " + c;

Update, in response to this comment: How to fix this ES6 module circular dependency?

To allow the end-user to import any subset of the classes, just make a lib.js file exporting the public facing api:

import A from "./A";
import B from "./B";
import C from "./C";
export { A, B, C };

or:

import A from "./A";
import B from "./B";
import C from "./ConcreteCImplementation";
export { A, B, C };

Then you can:

// --- Entrypoint

import { C } from "./lib";
const c = new C();
const output = ["Entrypoint", C, c];
console.log.apply(console, output);
document.getElementById("out").textContent = output.join();

Answer 3

All the previous answers are a bit complex. Shouldn't this be solved with "vanilla" imports?

You can just use a single master index, from which all symbols are imported. This is simple enough that JS can parse it and solve the circular import. There's a really nice blog post that describes this solution, but here it is according to the OP's question:

// --- Module A

import C from './index.js'
...

// --- Module B

import C from './index.js'
...

// --- Module C

import {A, B} from './index.js'
...

// --- index.js
import C from 'C'
import A from 'A'
import B from 'B'
export {A, B, C}

// --- Entrypoint

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

The order of evaluation is the order in index.js (C-A-B). Circular references in the body of declarations can be included this way. So, for example, if B and C inherit from A, but A's methods contain references to B or C (which would throw an error if importing normally), this will work.

Answer 4

Throwing another contender into the mix: a blog post by Michel Weststrate

The internal module pattern to the rescue!

I have fought with this problem on multiple occasions across many projects A few examples include my work at Mendix , MobX, MobX-state-tree and several personal projects. At some point, a few years ago I even wrote a script to concatenate all source files and erase all import statements. A poor-mans module bundler just to get a grip on the module loading order.

However, after solving this problem a few times, a pattern appeared. One which gives full control on the module loading order, without needing to restructure the project or pulling weird hacks! This pattern works perfectly with all the tool-chains I’ve tried it on (Rollup, Webpack, Parcel, Node).

The crux of this pattern is to introduce an index.js and internal.js file. The rules of the game are as follows:

1. The internal.js module both imports and exports everything from every local module in the project
2. Every other module in the project only imports from the internal.js file, and never directly from other files in the project.
3. The index.js file is the main entry point and imports and exports everything from internal.js that you want to expose to the outside world. Note that this step is only relevant if your are publishing a library that is consumed by others. So we skipped this step in our example.

Note that the above rules only apply to our local dependencies. External module imports are left as is. They are not involved in our circular dependency problems after all. If we apply this strategy to our demo application, our code will look like this:

// -- app.js --
import { AbstractNode } from './internal'

/* as is */

// -- internal.js --
export * from './AbstractNode'
export * from './Node'
export * from './Leaf'

// -- AbstractNode.js --
import { Node, Leaf } from './internal'

export class AbstractNode {
   /* as is */
}

// -- Node.js --
import { AbstractNode } from './internal'

export class Node extends AbstractNode {
   /* as is */
}

// -- Leaf.js --
import { AbstractNode } from './internal'

export class Leaf extends AbstractNode {
   /* as is */
}

When you apply this pattern for the first time, it might feel very contrived. But it has a few very important benefits!

1. First of all, we solved our problem! As demonstrated here our app is happily running again.
2. The reason that this solves our problem is: we now have full control over the module loading order. Whatever the import order in internal.js is, will be our module loading order. (You might want check the picture below, or re-read the module order explanation above to see why this is the case)
3. We don’t need to apply refactorings we don’t want. Nor are we forced to use ugly tricks, like moving require statements to the bottom of the file. We don’t have to compromise the architecture, API or semantic structure of our code base.
4. Bonus: import statements will become much smaller, as we will be importing stuff from less files. For example AbstractNode.js has only on import statement now, where it had two before.
5. Bonus: with index.js, we have a single source of truth, giving fine grained control on what we expose to the outside world.

Answer 5

UPDATE: I'm going to leave this answer up for posterity, but nowadays I use this solution.

---

Here is a simple solution that worked for me. I initially tried trusktr's approach but it triggered weird eslint and IntelliJ IDEA warnings (they claimed the class was not declared when it was). The following solution is nice because it eliminates the dependency loops. No magic.

1. Split the class with circular dependencies into two pieces: the code that triggers the loop and the code that does not.
2. Place the code that does not trigger a loop into an "internal" module. In my case, I declared the superclass and stripped out any methods that referenced subclasses.
3. Create a public-facing module.

• import the internal module first.
• import the modules that triggered the dependency loop.
• Add back the methods that we stripped out in step 2.

4. Have the user import the public-facing module.

OP's example is a little contrived because adding a constructor in step 3 is a lot harder than adding normal methods but the general concept remains the same.

internal/c.js

// Notice, we avoid importing any dependencies that could trigger loops.
// Importing external dependencies or internal dependencies that we know
// are safe is fine.

class C {
    // OP's class didn't have any methods that didn't trigger
    // a loop, but if it did, you'd declare them here.
}

export {C as default}

c.js

import C from './internal/c'
// NOTE: We must import './internal/c' first!
import A from 'A'
import B from 'B'

// See http://stackoverflow.com/a/9267343/14731 for why we can't replace
// "C.prototype.constructor" directly.
let temp = C.prototype;
C = function() {
  // this may run later, after all three modules are evaluated, or
  // possibly never.
  console.log(A)
  console.log(B)
}
C.prototype = temp;

// For normal methods, simply include:
// C.prototype.strippedMethod = function() {...}

export {C as default}

All other files remain unchanged.

Answer 6

There is another possible solution..

// --- Entrypoint

import A from './app/A'
setTimeout(() => console.log('Entrypoint', A), 0)

Yes it's a disgusting hack but it works

Answer 7

You can Solve it with dynamically loading modules

I had same problem and i just import modules dynamically.

Replace on demand import:

import module from 'module-path';

with dynamically import:

let module;
import('module-path').then((res)=>{
    module = res;
});

In your example you should change c.js like this:

import C from './internal/c'
let A;
let B;
import('./a').then((res)=>{
    A = res;
});
import('./b').then((res)=>{
    B = res;
});

// See http://stackoverflow.com/a/9267343/14731 for why we can't replace "C.prototype.constructor"
let temp = C.prototype;
C = function() {
  // this may run later, after all three modules are evaluated, or
  // possibly never.
  console.log(A)
  console.log(B)
}
C.prototype = temp;

export {C as default}

For more information about dynamically import:

http://2ality.com/2017/01/import-operator.html

There is another way explain by leo, it just for ECMAScript 2019:

https://stackoverflow.com/a/40418615/1972338

For analyzing circular dependency, Artur Hebda explain it here:

https://railsware.com/blog/2018/06/27/how-to-analyze-circular-dependencies-in-es6/