Summary of CommonJS module specification usage in Node.js

Javascript inherently lacks one feature: modules, and the emergence of the CommonJS specification makes up for this shortcoming.With the emergence of the CommonJS specification, front-end and back-end Javascript can be unified. Node draws on the Modules specification of CommonJS to implement a very easy-to-use module system.

1. CommonJS module specification

The module specification of CommonJS is divided into 3 parts:

1). Module reference: through require () method and pass in a module identifier to introduce the API of a module into the current context, such as var math = require('math');
2). Module definition: Export the methods of the current module through the exports object or variable. There is also a module object in the module, and exports are actually attributes of the module. In Node, a file is a module, and the "global variables" within the module are not visible to the outside world. Only the attributes mounted on exports are public, such as exports.add = function() {}; exports.PI = 3.1415926;
3). Module identification: It is actually the parameter passed to require(), such as the above 'math', which must be a string that conforms to the camel nomenclature, or start with "." ".." The relative path or absolute path at the beginning, it can not have the file name suffix ".js"

2. Node module implementation process

In Node, the module is divided into two Class: One type is the core module provided by Node itself, and the other type is the file module written by the user. Part of the core module is compiled into a binary file during the compilation process of Node source code. The core module is loaded directly into the memory when Node starts, so its loading speed is the fastest. The file module is dynamically loaded at runtime and requires three steps: path analysis, file location, and compilation and execution. Note that Node caches imported modules to reduce the cost of secondary introduction, and adopts the strategy of loading from the cache with the highest priority for secondary loading of the same module.

2.1 Path analysis

Path analysis mainly analyzes the module identifiers mentioned above, which are mainly divided into the following categories:

1), core Modules, such as http, fs, path, etc.
2), relative path file modules starting with . or ..
3), absolute path file modules starting with /
4), custom file modules, May be in the form of a file or package. Node will try to find the target file one by one according to the module path array module.paths. It usually searches for the directory named node_modules along the current directory step by step until the root directory, so this is the most time-consuming way to find it.

2.2 File location

Based on path analysis, file location needs to pay attention to the following details:

1), file extension analysis: due to The CommonJS specification allows the module identifier to not fill in the extension. Node will fill in the extension in the order of .js, .json, and .node, and try
2), directory analysis, and package in order: If no search is found after the above file extension analysis Go to the corresponding file, but get a directory. Node will treat the directory as a package

2.3 Compile and execute

After locating the specific file, Node will create a new module Object, loaded and compiled according to the path. For different extensions, the loading method is different:

1), .js file: read the file synchronously through the fs module and compile and execute
2), .node file: this is using C /Extension files written in C++, loaded through the dlopen() method
3), .json files: read the file synchronously through the fs module, and use JSON.parse() to parse and return the result
4), other extension files : are loaded as .js files

We know that each module file has three variables: require, exports, and module by default. Even in Node's API documentation, we know that each module also has There are two variables, filename and dirname. Where do they come from? How does Node's module ensure that the declared "global variables" do not actually contaminate other modules? In fact, Node wraps the file contents head and tail during the compilation process of JS modules. The following is an example of a JS file that is packaged from head to tail:

(function(exports, require, module, __filename, __dirname) { /* 中间是JS文件的实际内容 */ var math = require('math'); exports.area = function(radius) { return Math.PI * radius * radius; }; /* JS文件的实际内容结束 */ });

In this way, scope isolation is performed between each module file, and variables such as require, exports, and module are also injected into the context of the module. This is Node's implementation of the CommonJS module specification. The compilation process of C/C++ modules and Node core modules is relatively complicated and will not be described in detail.

3. Module call stack

It is necessary to clarify the calling relationship of various modules in Node, as shown in the following figure:

The C/C++ built-in module is the lowest module and is a core module. It mainly provides APIs for Javascript core modules and third-party Javascript file modules to call. In practice, such modules are almost never exposed. The Javascript core module has two main responsibilities: one is to serve as the encapsulation layer and bridging layer of C/C++ built-in modules for file module calls, and the other is a pure functional module that does not need to deal with the underlying layer. File modules are usually written by third parties, including ordinary Javascript modules and C/C++ extension modules.

4. Packages and NPM

4.1 Package structure

A package is essentially an archive file (usually .zip or .tar.gz), which can be decompressed and restored to a directory after installation. The CommonJS package specification consists of two parts: package structure and package description file. A package structure that fully complies with the CommonJS specification should contain the following files:

1).package.json: package description file
2).bin: directory where executable binary files are stored
3). lib: Directory for storing Javascript code
4).doc: Directory for storing documents
5).test: Directory for storing unit test cases

4.2 Package description file

The package description file is a JSON file - package.json, located in the root directory of the package. It is an important part of the package and is used to describe the general information of the package. All behaviors of NPM to be mentioned later are closely related to the fields of this file. The following uses the package.json file of the well-known Web framework express project as an example to illustrate the meaning of some common fields.

1).name: Package name
2).description: Package introduction
3).version: Version number, must comply with "semantic version control", refer to http://semver .org/
4).dependencies: List of packages that are required to use the current package. This attribute is very important. NPM will automatically load dependent packages through this attribute.
5).repositories: List of locations where source code is hosted.

For the usage of other fields, please refer to the NPM package.json description.

4.3 NPM common functions

NPM (node package manager), usually called the node package manager. Its main function is to manage node packages, including: installation, uninstallation, update, view, search, release, etc.

4.3.1 NPM package installation

There are two types of Node package installation: local installation and global installation. The difference between the two is as follows:

1). Local installation npm install : The package will be downloaded to the current directory and can only be used in the current directory.
2). Global installation npm install -g : The package will be downloaded to a specific system directory, and the installed package can be used in all directories.

4.3.2 NPM package management

The following takes grunt-cli (grunt command line tool) as an example to list commonly used package management commands:

1).npm install: Install all packages declared in the dependencies and devDependencies fields of the package.json file
2).npm install grunt-cli@0.1.9: Install a specific version of grunt-cli
3) .npm install grunt-contrib-copy --save: Install grunt-contrib-copy and save the dependency to the package.json file
4).npm uninstall grunt-cli: Uninstall the package
5).npm list : Check which packages are installed
6).npm publish : Publish packages

The above is the detailed content of Summary of CommonJS module specification usage in Node.js. For more information, please follow other related articles on the PHP Chinese website!