Node. js package Overview

Node. js package Overview

Author: chszs, reprinted with note. Blog homepage: http://blog.csdn.net/chszs

In node. in JS language, packages and modules are not essentially different. packages are further abstracted Based on modules. Packages encapsulate an independent function, it is used for release, update, dependency management, and version control. Node. js implements the package mechanism according to commonjs specifications, and develops NPM to meet the package release and acquisition requirements.

The node. js package is a directory containing the package. JSON file in JSON format. The node. js package follows the commonjs specification, so it has the following features:

Package features defined by commonjs specifications:
1) the top-level directory contains the package. JSON file;
2) The bin directory stores binary files;
3) The lib directory stores JavaScript files;
4) store documents in the doc directory;
5) store the unit test in the test directory.

Node. js modules correspond to files in a one-to-one manner. files can not only be JavaScript source code files or binary files, but also directories. The simplest package is a directory module.

The node. js package is usually a collection of some modules. It provides high-level abstraction on the basis of the module, which is equivalent to providing some fixed interface function libraries.
By customizing package. JSON, we can create more complex, more comprehensive, and more compliant packages for release.

Node. when JS calls a package, it first checks the package in the package. the main field of the JSON file, which is used as the interface module of the package. the main field of the JSON file does not exist, so node. JS will try to find the index. JS or index. node is the package interface.

The package. JSON file is the file used to describe the package in commonjs specifications. The fully compliant package. JSON file should contain the following fields:
1) Name: package name. The package name is unique and consists of lower-case letters, numbers, and underscores. It cannot contain spaces.
2) Description: Package Description. Briefly describe the package.
3) version: version number. The version string that meets the semantic version recognition specification.
4) KEYWORDS: a keyword array, usually used for search.
5) maintainers: the maintainer array. Each element contains the name, email (optional), and Web (optional) fields.
6) Contributors: A contributor array. The format is the same as that of the maintainer array. The package author should be the first element of the contributor array.
7) bugs: the address for submitting a bug. It can be a website or email address.
8) licenses: License array. Each element must contain the type (license name) and URL (URL linked to the license text) fields.
9) repositories: array of repository hosting addresses. Each element must contain the type (repository type, such as GIT), URL (repository address), and path (optional) fields.
10) dependencies: package dependency. Is an associated array consisting of the package name and version number.

Note: The semantic version recognition specification is a set of version naming rules proposed by foreign countries. Its initial goal is to solve various version number comparison problems and is currently used by many package management systems.

The following is an example of package. JSON that fully complies with commonjs specifications:

{"Name": "testpackage", "Description": "My package for commonjs. "," version ":" 0.1.0 "," keywords ": [" testpackage "," liq "]," maintainers ": [{" name ":" liq ", "email": "liq@hotmail.com",}], "contributors": [{"name": "liq", "Web": "http://blog.csdn.net/chszs"}], "bugs ": {"mail": "liq@hotmail.com", "Web": "http://blog.csdn.net/chszs"}, "licenses": [{"type": "Apache license V2", "url ": "http://www.apache.org/licenses/apache2.html"}], "repositories": [{"type": "Git", "url": "http://github.com/chszs/packagetest.git"}], "dependencies": {"WebKit ": "1.2", "SSL": {"gnutls": ["1.0", "2.0"], "OpenSSL": "0.9.8 "}}}