What are module cycle dependencies

Nodejs is known to preload modules into memory. When all modules are loaded, the entire application is run from the entry file. If all modules rely on each other sequentially, there is no problem, just like snake. It just depends on the chain being longer, but if the snake accidentally bites the body or the tail, it will loop, like in the code

//a.js
console.log('a starting');
exports.done = false;
const b = require('./b.js');
console.log('in a, b.done = %j', b.done);
exports.done = true;
console.log('a done');

//b.js
console.log('b starting');
exports.done = false;
const a = require('./a.js');
console.log('in b, a.done = %j', a.done);
exports.done = true;
console.log('b done');

//main.js
console.log('main starting');
const a = require('./a.js');
const b = require('./b.js');
console.log('in main, a.done = %j, b.done = %j', a.done, b.done);
Copy the code

This is an example of Nodejs, as in the example, A. JS read require B.js, then run to B.js, b.js read require A.js, then run to A.js, If you are like a browser, you should start parsing again. After all, there is no reason to leave things half-done. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah ?

This is the problem of module cyclic dependencies

To solve this problem, Nodejs can be described as simply unfinished Copy, with Nodejs called Unfinished Copy. When entering the A.js module, read from the end of require B.js, This undoes the loop and goes back to the old serial way of parsing. The trade-off is that you have to know what is written before and after require, especially when it comes to exports, which are not the same because of the order of execution. But what if we want to read the whole thing without interrupting?

Then we need to separate Module parsing and Module loading, such as the import we bring with the ES6 Module

//a.js
import b from 'b.js'
import c from 'c.js'. coding...//b.js
import a from 'a.js'. coding...Copy the code

The code execution is divided into two phases, which means that no matter where you write the import code, it will be read before any other code. This also solves the problem that the order of code execution before and after require causes the export value to be inconsistent. Since the order starts with import, from this point of view it would be more intuitive if require’s design were to remove the concept of module, such as requiring a fragment rather than a module, because it’s a super-large script, But adding modules is a bit counter-intuitive, because we all feel that modules are separate from modules, and a module load is split because of require… It feels like design disability is not so much Unfinished copy as unfinished module. So using copy instead of Module and calling it CommonJS Copy might be more realistic.

Back to the point, by resolving the load separation, we can resolve module dependencies without reading the actual module code. In A. js we read the import ‘b.js’. At this point we can add a State to b.js and set it to ‘Linked’. From b.js to import A.js, we set the State of A.js to ‘Linked’, then go back to A.js, and find that B.js is Linked already, skip, Continue reading c.js, avoiding cyclic dependencies through status markers

Import the gift tree-shaking

Tree-shaking is a solution to remove dead code from rollup. The idea of Shaking trees comes from how rollup converts code into an AST and shakes it. Unuesed variables/functions/classes, etc. The premise of doing this is actually import-based static analysis. Based on static analysis, you can first analyze the exported objects of the Module itself, and all objects imported by other modules, and find those variables that are not used in the exported objects. Then analyze whether these variables are used from the Module itself. If not, shake them off. And there are hidden meanings behind shaking a tree, like what falls when we shake it hard! ?

Nature is —- leaf…

The leaves that fall in the AST are those nodes, so tree shaking, or tree shaking is not very graphic 😁

However, tree-shaking actually uses two basic data deconstructions, graphs and trees, so it is necessary to learn data structures well 😀 (speaking of which, I have gone back to work… 😢)

CommonJS -> ES6 Module

The design of Import is further than require. It not only solves problems but also introduces optimizable solutions. Based on Import, tree-shaking technology can be developed to further optimize construction, which is the significance of technological progress. Import also leaves extended support for remote modules. Importing a remote module, as Deno does, is probably worse at runtime. If a loaded module becomes unavailable, it affects all associated modules, which is almost disastrous for large applications. Itself, because the network environment is not stable, plus the incomprehensibility of the network environment, it will make the module system itself in a situation of not available, but if it is a static analysis, we can advance the usability of the test module, the involvement of the network will make problem is complex, and rely on the analysis and loading decoupling can also be very good to support for this scene, So the Import specification design based on static analysis is actually great, and designs like this that support the future are great designs! ? (So it is worth studying hard and thinking deeply)

The latter

The ES6 Module is a great design, but it’s a little sad to write this article, because most of these low-level standard designs are foreigners, well basically foreigners, and there is not much discussion about this low-level standard/specification design in China. For example, the implementation of Require or the design of the CommonJS Module is flawed, but it doesn’t get much attention, or it gets much attention but it doesn’t get much discussion, and we seem to be conditioned to accept some kind of well known design or to accept some kind of standard that already exists, and not to think independently or even question it, Question why this design

Sometimes I feel the front circle like a investment circles, we seem to keep chasing a tuyere, another technology that gave birth to the famous speech “learn to move” actually this kind of speech is our pursuit to the technology behind the tuyere feeling tired, because most people have not benefited, as if the investment circle is always that a few bosses make money, Ordinary people are leek, do not believe? You look at the leeks in the currency circle of the stock market

Maybe we can stop and think about something, question something, not just chase it.