In the Node.js language, there is no essential difference between packages and modules. Packages are a deeper abstraction based on modules. Packages encapsulate a certain independent function for release, update, dependency management and version control. Node.js implements the package mechanism according to the CommonJS specification and develops npm to solve the package release and acquisition needs.
The Node.js package is a directory containing the package description file package.json in JSON format. The Node.js package basically follows the CommonJS specification, so it has the following characteristics:
Package features defined by the CommonJS specification:
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) The doc directory stores documents;
5) The test directory stores unit tests.
The Node.js module and file correspond one by one. The file can not only be a JavaScript source file or binary file, but also a directory. The simplest package is a directory module.
The Node.js package is usually a collection of some modules, which provides higher-level abstractions based on modules, which is equivalent to providing some fixed interface function libraries.
By customizing package.json, we can create more complex, more complete and more standardized packages for publishing.
When Node.js calls a package, it first checks the main field of the package.json file in the package and uses it as the package interface module. If the main field of the package.json file does not exist, Node.js will try to find index.js or index.node as the package interface.
The package.json file is a file used by the CommonJS specification to describe the package. The package.json file that fully complies with the specification should contain the following fields:
1) name: package name. The package name is unique and consists of lowercase letters, numbers and underscores, and cannot contain spaces.
2) Description: Package description. A brief description of the package.
3) version: version number. Version string that meets the Semantic Version Recognition specification.
4) keywords: keyword array, usually used for search.
5) Maintainers: maintainers array. Each element contains the name, email (optional), and web (optional) fields.
6) Contributors: Array of contributors. The format is the same as the maintainer array. The package author should be the first element of the contributor array.
7) Bugs: The address to submit the bug can be a URL or email address.
8) licenses: license array. Each element must contain the type (license name) and url (address linked to the license text) fields.
9) repositories: an array of repository hosting addresses. Each element must contain the type (type of the repository, such as Git), url (repository address), and path (optional relative to the repository path).
10) dependencies: package dependencies. is an associative array consisting of package name and version number.
Note: The "Semantic Version Recognition" specification is a set of version naming specifications proposed by foreign countries. The original purpose was to solve various version number size comparison problems, and is currently adopted by many package management systems.
Here is an example package.json that fully complies with the CommonJS specification:
The code copy is as follows:
{
"name": "testpackage",
"description": "My package for CommonJS.",
"version": "0.1.0",
"keywords": [
"testpackage",
"liq"
],
"maintainers": [
{
"name": "liq",
"email": "[email protected]",
}
],
"contributors": [
{
"name": "liq",
"web": "http://blog.csdn.net/chszs"
}
],
"bugs": {
"mail": "[email protected]",
"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"
}
}
}