Principle of introducing modules into node

1. Module mechanism

1.1 commonjs standard

1. CommonJS The specification is JavaScript Made a beautiful vision —— hope JavaScript Can run anywhere .
2. CommonJS The definition of modules is very simple , It is mainly divided into Module reference 、 Module definition and module identification 3 Parts of .

• Module reference ： adopt require Method Introduce modules

var math = require('math');

• Module definition ： adopt exports Object to export the methods or variables of the current module （exports yes module Properties of ）

exports.add = function() {
    }

• Module identifier ： Is to pass it on to require Method parameters , It can be in the following forms （ There can be no file suffix .js）：
  • A string that matches the name of a small hump
  • With .、… The relative path at the beginning
  • Absolute path

1.2 node Module implementation of （node Process of introducing modules in ）

node It's not exactly in accordance with connonjs standard , It is a certain choice of module specification , At the same time, it adds a little of its own characteristics .

1. stay node The introduction of the module in the requires the following 3 A step ：

• Path analysis
• File location
• Compile implementation

2. node in , Modules are divided into the following two categories ：

• Core module ：node Module provided
  • The core modules are node During source code compilation , Compiled into binary execution file
  • stay node When the process starts , The core module is loaded directly into the memory （ So this part of the core module is introduced , File location and compilation execution can be omitted , And in Priority judgment in path analysis , The fastest loading speed ）
• File module ： User written modules
  • Need to load dynamically at runtime , A complete path analysis is needed 、 File location and compilation execution . Slower

The following is the detailed module loading process :

1.2.1 Load from cache first

• node All the introduced modules will be cached , To reduce the cost of secondary Introduction （ The difference from browser caching is ： Browsers only cache files , and node The cache is the compiled and executed objects ）
• Cache checking of core modules takes precedence over file modules

1.2.2 Path analysis

Because there are several forms of identifiers , So for different identifiers , There are different degrees of differences in the search and location of modules . Modules are classified as follows ：

• Core module ： Such as http、fs、path etc.
• With . or … Start the relative path file module
• With / Start the absolute path file module
• Non path file module , Such as customized file module

1. Core module
The priority of core modules is second only to cache loading , It's in node The source code is compiled into binary files during compilation , The fastest loading speed .

2. File module in the form of path
require Meeting Convert path to real path , And take the real path as the index , Put the compiled results into the cache , To make the secondary load faster .

3. Custom module
node I'll try one by one The module path In the path , Until the target file is found .

• Module path concept ： The module path yes node The search strategy specified when locating the specific file of the file module , The specific performance is a An array of paths ( It can be done by module.paths Output )
• Generation rules of module path ：
  • In the current file directory node_modules Catalog
  • In the parent directory node_modules Catalog
  • Under the parent directory of the parent directory node_modules Catalog
  • Recursion step by step up the path , Until... In the root directory node_modules Catalog

1.2.3 File location

• Analysis of file extensions
• Directory and package processing

1. Analysis of file extensions ： When passed to the require When the identifier of does not include the file extension ,node The extensions will be supplemented in the following order , Try... In turn ：

• .js
• .json
• .node

In the process of trying ,node Would call fs Module synchronization block determines whether the file exists . because node It's single threaded , So here is a place that will cause performance problems .（ solve : In the introduction of .json and .node When you file , Add extension ）

2. Directory and package processing ：require After analyzing the file extension , What you might get is a directory , here node The directory will be treated as a package .

• First ,node Find in current directory package.json. adopt json.parse Parse out the package description object , Take it out of it main Property Analyze , If extension is missing , You will enter the extension analysis step .
• if main The specified file name is incorrect , Or not package.json, that node Will index As the file name . Then look for index.js、index.json、index.node
• If you do not successfully locate any files during directory analysis , Then the custom module will Go to the next module path and continue to find . If the module path has not been traversed , An exception will be thrown if the search fails .

1.2.4 Module compilation

After locating the specific file ,node A new module object will be created , Then load and compile according to the path . For different extensions , The loading method is as follows ：

• .js file ： adopt fs modular Compile and execute after synchronously reading files
• .node file ： This is the use of c/c++ Write the extension file , adopt dlopen Load the last compiled file
• .json file ： adopt fs modular After reading the file synchronously , use Json.parse Parsing returns results
• The rest of the extension files ： It's all taken for granted .js File loading

notes ： Each successfully compiled module , Will cache its file path as an index in Module._cache On the object , To improve the performance of secondary Introduction

1. js Module compilation
node Acquired js The document is packed from beginning to end , The packaged code will go through vm Native module's runInThisContext() perform

(function(exports, requiure, module, __filename, __dirname){
    
    ...
}

2. c/c++ Module compilation
node call process.dlopen() Load and execute ,（dlope stay windows and *nux The platform passes libuv Compatible with ）.node Modules do not need to be compiled , Because he wrote c/c++ The module is compiled and generated .

3. json File compilation

• adopt fs The module synchronously reads json The content of the document
• adopt JSON.parse() Get the object
• Copy to module.exports

1.3 Core module

• c/c++ To write （ Store in node Of src Catalog ）
• js To write （ Store in lib Catalog ）

1.3.1 js Compilation process of core modules

• Transfer to c/c++ Code ：node adopt v8 Incidental js2c.py Tools , All built-in js Code to c++ Array in , Generate node_natives.h The header file .（ In the process ,js The code is stored as a string in node In the namespace . Start up node Process time ,js The code is loaded directly into memory ）
• compile js Core module ： Also experienced the packaging process from beginning to end （ The difference from the file module is ： How to get the source code and where to cache the execution results ）
  • The core module is loaded from memory
  • Successfully compiled modules are cached in NativeModule._cache object ; The file module is cached to Module._cache object

1.3.2 c/c++ Compilation process of core modules

• Built in module ： All by c/c++ To write （ Such as buuffer、fs、os etc. ）
• c/c++ Complete the core part ,js Implement encapsulation

1. Built in module

• After each built-in module is defined , All pass NODE_MODULE Macros define modules to node In the namespace .
• nodex_extensions.h The header file puts these hash built-in modules into node_module_list Array
• node Provides get_builtin_module() from node_module_list Take out the built-in module
• Export of built-in modules ： adopt process.binding() To load built-in modules （process yes node Global variables generated at startup ）

1.3.3 Introduction process of core modules

• NODE_MODULE(node_os, reg_func)
• get_builtin_module(‘node_os’)
• process.binding(‘os’)
• NativeModule.require(‘os’)
• require(‘os’)

1.4 c/c++ Extension module

• Module writing ：

The difference between an ordinary extension module and a built-in module is ： There is no need to compile the source code into node, But through dlopen() Dynamic loading

• Module compilation ： adopt gpy Tools

• Module loading ： adopt require() load

  • about .node Files use process.dlopen() load

    • adopt uv_dlopen（） Open the DLL
    • adopt uv_dlsym() Find the dynamic link library through NODE_MODULE Macro defined method address

    （ notes ： Both of the above methods are based on libuv Implemented in the library . In different operating systems, call different methods to load .node The corresponding file under the operating system .so and .dll）