Ruan Yifeng: Cyclic loading of JavaScript modules

"Circular dependency" means that the execution of script a depends on script b, and the execution of script b depends on script a.

 // a.js  
 var b = require( 'b' ); 
 
 // b.js  
 var a = require( 'a' );

Generally, "cyclic loading" indicates strong coupling, and if not handled properly, it can lead to recursive loading, making the program unexecutable, so it should be avoided.

[[154576]]

But in reality, this is difficult to avoid, especially in large projects with complex dependencies, where it is easy for a to depend on b, b to depend on c, and c to depend on a. This means that the module loading mechanism must consider the situation of "cyclic loading".

This article introduces how JavaScript handles "cyclic loading". Currently, the two most common module formats, CommonJS and ES6, have different processing methods and return different results.

CommonJS modules

The important feature of CommonJS modules is that they are executed when loaded, that is, the script code will be executed in full when it is required. Therefore, CommonJS stipulates that once a module is found to be "loaded in a loop", the loading will be stopped immediately and only the executed part will be output.

Let's take a look at the example in the official documentation. The code of the script file a.js is as follows.

 exports.done = false ;
 var b = require( './b.js' );
 console.log( 'In a.js, b.done = %j' , b.done);
 exports.done = true ;
 console.log( 'a.js completed execution' );

In the above code, the a.js script first outputs a done variable, and then loads another script file b.js. Note that the a.js code stops here and waits for b.js to finish executing before continuing.

Let’s look at the code of b.js again.

 exports.done = false ;
 var a = require( './a.js' );
 console.log( 'In b.js, a.done = %j' , a.done);
 exports.done = true ;
 console.log( 'b.js completed execution' );

In the above code, when b.js executes to the second line, it will load a.js. At this time, "loop loading" occurs. In order to avoid infinite recursion, the execution engine will not execute a.js again, but only return the executed part.

The executed part of a.js is only one line.

 exports.done = false ;

Therefore, for b.js, it only inputs one variable done from a.js, and the value is false.

Then, b.js continues to execute until all execution is completed, and then returns the execution right to a.js. So, a.js continues to execute until the execution is completed. Let's write a script main.js to verify this process.

 var a = require( './a.js' );
 var b = require( './b.js' );
 console.log( 'In main.js, a.done=%j, b.done=%j' , a.done, b.done);

Execute main.js and the results are as follows.

 $ node main.js 
 
 In b.js, a.done = false  
 b.js is executed
 In a.js, b.done = true  
 a.js is executed
 In main.js, a.done = true , b.done = true  

The above code proves two things. First, a.js is not completely executed in b.js, only the first line is executed. Second, when main.js executes to the second line, it will not execute b.js again, but output the cached execution result of b.js, that is, its fourth line.

 exports.done = true ;

ES6 modules

The operating mechanism of ES6 modules is different from that of CommonJS. When it encounters the module loading command import, it will not execute the module, but only generate a reference. When it is really needed, it will then get the value from the module.

Therefore, ES6 modules are dynamically referenced, there is no problem of cached values, and the variables in the module are bound to the module it is in. Please see the example below.

 // m1.js  
 export var foo = 'bar' ;
 setTimeout(() => foo = 'baz' , 500 ); 
 
 // m2.js  
 import {foo} from './m1.js' ;
 console.log(foo);
 setTimeout(() => console.log(foo), 500 );

In the above code, the variable foo of m1.js is equal to bar when it is first loaded, and becomes equal to baz after 500 milliseconds.

Let's see if m2.js can read this change correctly.

 $ babel-node m2.js 
 
 bar
 baz

The above code shows that ES6 modules do not cache the running results, but dynamically get the values ​​of the loaded modules, and the variables are always bound to the module in which they are located.

This makes ES6's handling of "cyclic loading" fundamentally different from CommonJS. ES6 does not check whether "cyclic loading" has occurred at all, but only generates a reference to the loaded module. It is up to the developer to ensure that the value can be obtained when the value is actually obtained.

See the following example (taken from Dr. Axel Rauschmayer's Exploring ES6).

 // a.js  
 import {bar} from './b.js' ;
 export function foo() {
 bar();
 console.log( 'Execution completed' );
 }
 foo(); 
 
 // b.js  
 import {foo} from './a.js' ;
 export function bar() {
 if (Math.random() > 0.5 ) {
 foo();
 }
 }

According to the CommonJS specification, the above code cannot be executed. a first loads b, and then b loads a. At this time, a has not yet executed any results, so the output result is null. That is, for b.js, the value of the variable foo is equal to null, and the subsequent foo() will report an error.

However, ES6 can execute the above code.

 $ babel-node a.js 
 
 Execution completed

The reason why a.js can be executed is that the variables loaded by ES6 are all dynamically referenced to the module they are in. As long as the reference exists, the code can be executed.

Let's look at an example given by the ES6 module loader SystemJS.

 // even.js  
 import { odd } from './odd'  
 export var counter = 0 ;
 export function even(n) {
 counter++;
 return n == 0 || odd(n - 1 );
 } 
 
 // odd.js  
 import { even } from './even' ;
 export function odd(n) {
 return n != 0 && even(n - 1 );
 }

In the above code, the function foo in even.js has a parameter n. As long as it is not equal to 0, it will subtract 1 and pass it into the loaded odd(). odd.js will also do a similar operation.

Running the above code, the results are as follows.

 $ babel-node
 > import * as m from './even.js' ;
 > m.even( 10 );
 true  
 > m.counter
 6  
 > m.even( 20 )
 true  
 > m.counter
 17  

In the above code, when the parameter n changes from 10 to 0, foo() will be executed 6 times in total, so the variable counter is equal to 6. When even() is called for the second time, the parameter n changes from 20 to 0, and foo() will be executed 11 times in total, plus the previous 6 times, so the variable counter is equal to 17.

If this example is rewritten as CommonJS, it will not be executable at all and will report an error.

 // even.js  
 var odd = require( './odd' );
 var counter = 0 ;
 exports.counter = counter;
 exports.even = function(n) {
 counter++;
 return n == 0 || odd(n - 1 );
 } 
 
 // odd.js  
 var even = require( './even' );
 exports.odd = function(n) {
 return n != 0 && even(n - 1 );
 }

In the above code, even.js loads odd.js, and odd.js loads even.js, forming a "loop loading". At this time, the execution engine will output the part that even.js has executed (there is no result), so in odd.js, the variable even is equal to null, and an error will be reported when even(n-1) is called later.

 $ node
 > var m = require( './even' );
 > m.even( 10 )
 TypeError: odd is not a function

(over)