Cortex dependency management

Cortex depends on modules based onSemantic versionManagement. If you are familiar with NPM module management, you will understandNodeThe module is placed inNode_modulesIn this directory, each module's own dependencies are stored in its own directoryNode_modulesThis avoids version conflicts between different modules.

650) This. width = 650; "src =" http://media.tumblr.com/afe698d28d9ea909d6738d5f49818e45/tumblr_inline_n8hi3lufwP1sjo9e8.png "alt =" NPM nested structure "style =" border: 0px; "/>

In front-end development, nested dependency is impossible, because:

• 1) loading in Web development is asynchronous. It is very time-consuming to remotely detect the existence of dependencies on files as node does at runtime.

• 2) the file size limit, relative to the low cost of the disk, the overhead of HTTP requests and loading duplicate JS files on the page is very large, and it is impossible to implement it by means of file embedding.

Therefore, the module Management of cortex is based on a flat structure:

 

650) This. width = 650; "src =" http://media.tumblr.com/7c860f8b0956f067eaa2cc1d128cb85c/tumblr_inline_n8hgent4WM1sjo9e8.png "alt =" cortex flat "style =" border: 0px; "/>

How does a module know the version of the third-party module that needs to be loaded? For example, store. JS is used in the code

require(‘store.js‘)

This information only tells us which module is dependent, but does not know the specific version. Usually loader, suchRequirejsTo manage modules. The module ing is as follows:

"'Store. js =./MoD/store. js.1.0.0.js"

This is equivalent to a global variable. All store. js will be fixed to a specific version, even if a third-party dependency is not compatible with version 1.0.0.

Component and Bower also store modules in a flat manner, but there is only one directory. If these two different versions exist in the dependency tree, no matter whether they are compatible or not, only one version will be generated. The version depends entirely on the level, sequence, and execution of the dependency statement.InstallThe order in which asynchronous tasks are executed is random.

If a module A depends on a lower version of jquery, 1.8.3, and another Module B depends on 1.9.1, the final result cannot be controlled in component, depending on the position of jquery in the dependency tree, an error occurs when [email protected] is finally installed in a module.

Such errors are discovered only when the code is executed. For unfamiliar users, it is hard to realize that they are dependent on a module and need to be familiar with component, in addition, you can quickly find problems by understanding the dependencies in the modules you use.

In this way, both the developer and the user of the module need to manage the code compatibility problem. The user needs to understand the dependencies of the used module. Otherwise, he may encounter a bug that is hard to find. Any incompatible module will damage this ecological environment, so that developers do not dare to use existing modules to duplicate the wheel.

In cortex, correct version declarations allow only module developers to care about their module dependencies. Users do not have to worry that the deep components on the dependency tree will affect their own code. In the previous example, the developer of module A depends on[Email protected]Which can be declared:

[email protected]^1.8.3

Module B declares that:

[email protected]^1.9.1

In this way, cortex will find that [email protected] can meet two requirements to ensure compatibility, and the correct [email protected] will be loaded. The users of module A and Module B do not need to know which versions of jquery A and Module B use. They only need to manage a and Module B, and cortex will help them deal with deep-level dependencies.

Because other loaders are basically based on the "name => JS file" ing to load JS files, therefore, in the execution environment, it is impossible to differentiate the different meanings that names may represent in different codes. This is why cortex currently only supports neuron as loader.

With the version information, if two modules depend on the same version of store. JS, store. js will only load one copy instead of each of them. Cortex supports the range of the semantic version to declare the dependency, so that as long as the two versions are compatible, there will be no two pieces of code.

650) This. width = 650; "src =" http://media.tumblr.com/92a1ace356379a4a3746397ec50cff65/tumblr_inline_n8hl4xnnFa1sjo9e8.jpg "style =" border: 0px; "/>

For incompatible code, users do not have to worry about functional failure or the new version destroys the previous logic. Even if a page is referenced to different versions of a module at multiple levels, different codes are also compatible with each other. Such stability is very important for large projects.

In an environment with high performance requirements, you can optimize specific code. to exclude unnecessary files, you can run the following command:

cortex ls store.js

All store. js on the dependency tree will be listed. You can find out which module depends on the old version to upgrade or replace the dependency.