Packages in the Nodejs

Previous words

Node organizes its own core modules and enables third-party file modules to be written and used in an orderly fashion. However, in the third-party module, the module and the module are still scattered around, can not be directly referenced to each other. In addition to modules, packages and NPM are a mechanism for connecting modules. Before introducing NPM, we had to mention the COMMONJS package specification. JavaScript does not have a module and package structure like Java or other languages. Node's implementation of the module specification solves the problem of code organization such as variable dependency and dependency relationship to some extent. The appearance of the package is to further organize the JavaScript code on the basis of the module. The definition of COMMONJS package specification is also very simple, it consists of package structure and package description file two parts, the former is used to organize the various files in the package, the latter is used to describe the package related information for external read analysis. This article will detail the packages in Nodejs

Package structure

The package is actually an archive file, which is a directory that is packaged directly as a. zip or tar.gz file, and then decompressed to the directory after installation. The package directories that fully conform to the COMMONJS specification should contain the following files

1. Package.json: Package description file

2. Bin: Directory to store executable binaries

3. lib: Directory to store JavaScript code

4. Doc: Directory for storing documents

5. Test: Code for storing unit test cases

An example of the package structure of the Livereload plugin, which functions as an instant refresh of the page

Package description File

The package description file is used to express non-code related information, which is a JSON-formatted file--package.json, located at the root of the package, is an important part of the package. And all of NPM's behavior is tied to the fields of the package description file.

　　package.jsonFiles that define the various modules required for the project, as well as the configuration information for the project (such as name, version, license, and so on). The npm install command automatically downloads the required modules based on this configuration file, which is the run and development environment required to configure the project

With the Package.json file, the required modules are installed in the current directory using the NPM Install command directly.

$ NPM Install

If a module is not in package.json the file, you can install the module separately and use the corresponding parameters to write it to the package.json file

$ NPM Install Express----save-dev

The code above indicates that the Express module is installed separately, and the parameter indicates that the module is written to the property --save dependencies , --save-dev indicating that the module is written devDependencies to

Similarly, take the package description file of the Livereload plugin as an example

Basic fields

Package.json files can be written manually or npm init automatically generated using commands

$ NPM Init

This command takes an interactive approach, asks the user to answer some questions, and then generates a basic Package.json file in the current directory. Of all the issues, only the project name and project version (versions) are required, and the others are optional.

Therefore, the simplest Package.json file defines only two items of metadata: The project name and the project version

{  "name": "XXX",  "version": "0.0.0",}

1, name--package name. Specification definition it needs to consist of lowercase letters and numbers, which can contain., _, and-but no spaces are allowed. The package name must be unique to avoid a misunderstanding of conflicting names when published. In addition, NPM recommends that you do not include node or JS in the package name to repeatedly identify it as a JavaScript or node module

"Name": "Livereload"

2, version--version number. A semantic version number, which is defined in detail on http://semver.org/, usually in the major.minor.revision format. This version number is important and is often used in some version control scenarios

"Version": "0.6.0"

Required Fields

COMMONJS defines the 10 required fields, including name and version, for the Package.json file. However, since the COMMONJS package specification is still in the draft stage, NPM has made some trade-offs in practice.

1, description--package introduction. Convenient for others to understand the role of the module, search time also useful

"description": "Livereload Server"

2, keywords--keyword array, NPM is mainly used to do classification search. A good array of keywords helps users quickly find the package

[Note that the]livereload plugin does not have the keywords property set

3, maintainers--package maintainer list. Each maintainer consists of 3 attributes, name, email, and web

[Note that the]livereload plugin does not set the Web properties in maintainers

  "Maintainers": [    {      "name": "Bphogan",      "email": "[email protected]"    }  ] 

4. List of contributors--contributors. In the open source community, providing code for open source projects is a common occurrence, and if names can appear in the contributors list of well-known projects, it is a matter of pride. The first contribution in the list should be the author of the package. It has the same format as the maintainer list

  "Contributors": [    {      "name": "Brian P. Hogan",      "email": "[email protected]"    }  ]

5. bugs--a Web address or e-mail address that can feed back bugs

  "Bugs": {    "url": "Https://github.com/napcs/node-livereload/issues"  }

6. licenses--the list of licenses used by the current package, indicating which licenses the package can use

  "Licenses": [    {      "type": "MIT",      "url": "https://github.com/napcs/ Node-livereload/blob/master/license "    }  ]

7. repositories--the location list of the managed source code, indicating which ways and addresses can access the source of the package

  "Repository": {    "type": "Git",    "url": "Git+ssh://[email protected]/napcs/ Node-livereload.git "  }

8. dependencies--Use the list of packages that the current package needs to rely on. This property is important, and NPM will help automatically load dependent packages with this property.

The corresponding version can be combined with a variety of qualifications, mainly in the following categories:

• Specify version: for example, 1.2.2, follow the "large version. Minor version." The format specifies that only the specified version is installed when installing
• Greater than less than (> or <) + specified version: For example, >=1.2.2, the latest version of installation greater than or equal to 1.2.2
• Tilde (tilde) + specified version: ~1.2.2, for example, installs the latest version of 1.2.x (no less than 1.2.2), but does not install 1.3.x, which means that the large and minor version numbers are not changed during installation.
• Caret (caret) + specified version: ˆ1.2.2, for example, represents the latest version of the installation 1.x.x (no less than 1.2.2), but does not install 2.x.x, which means that the large version number is not changed during installation. It is important to note that if the large version number is 0, the caret behaves the same as the tilde, because at this point in development, even minor version number changes can lead to incompatible programs
• Latest: Install the latest version

  "Devdependencies": {    "coffee-script": ">= 1.8.0",    "Mocha": ">= 1.0.3",    "Request": ">= 2.9.203",    "should": ">= 0.6.3",    "Sinon": "^1.17.4"  } 

Optional fields

In addition to the required fields, the specification defines a subset of optional fields, as shown below

1, homepage--the current package of the website address

  "Homepage": "Https://github.com/napcs/node-livereload#readme",

2, os--operating system support list. The values for these operating systems include AIX, FreeBSD, Linux, MacOS, Solaris, VxWorks, Windows. If the list is set to NULL, no assumptions are made on the operating system

[Note that the]livereload plugin does not have OS properties set

3. The support list for the CPU--CPU architecture, with an effective architecture name of ARM, MIPS, PPC, SPARC, x86, and x86_64. As with the OS, if the list is empty, no assumptions are made on the CPU architecture

[Note that the]livereload plugin does not set the CPU properties

4. List of JavaScript engines supported by engine--, valid engine values include Ejs, Flusspferd, Gpsee, JSC, SpiderMonkey, Narwhal, node, and V8

  "Engines": {    "node": ">=0.4.0"  }

5, builtin--flag is the current package is built in the underlying system standard components

[Note that the]livereload plugin does not have the Builein property set

6, directories--Package directory description

"Directories": {}

7, implements--implementation of the list of specifications. Flags the current package implements what specifications are Commonjs

[Note that the]livereload plugin does not have the Implements property set

8. scripts--script Description object. It is primarily used by package managers to install, compile, test, and unload packages. scriptsSpecifies the NPM command line abbreviation for running script commands, such as Start specifying the run npm run start , the command to execute

  "Scripts": {    "test": "Mocha"  },

Other fields

In the specification of package profiles, NPM actually requires fields such as name, version, description, keywords, repositories, author, bin, Main, scripts, engines, dependencies, Devdependencies. The difference with the package specification is that the 4 fields of author, bin, Main, and devdependencies are more

1. author--Package Author

[Note that the]livereload plugin does not have the Author property set

2. bin--specifies the location of the executable file corresponding to each internal command. Some package authors want the package to be used as a command-line tool. Once you have configured the Bin field, you can add the script to the execution path via the NPM install PACKAGE_NAME-G command, which can then be executed directly on the command line. Module packages installed through the-G command are called global mode

The following code specifies that the executable file corresponding to the Livereaload command is livereload.js under the bin subdirectory. NPM will look for this file and node_modules/.bin/ create a symbolic link in the directory. In the example above, Livereaload will create symbolic links npm_modules/.bin/someTool . Because the node_modules/.bin/ directory joins the system's path variable at run time, it is possible to invoke these scripts directly from the command without a path when running NPM.

  "Bin": {    "livereload": "./bin/livereload.js"  }

As a result, the following wording can be used in shorthand

scripts: {    './node_modules/livereload.js build '}//  abbreviated to scripts: {     ' Livereload build '}

All node_modules/.bin/ commands in the directory can be run in npm run [命令] the same format. At the command line, type npm run , and then press the TAB key to display all the commands that you can use

3, main--loading the import file. Module Introduction method require () when the package is introduced, this field is first checked and used as the entry point for the rest of the modules in the package. If this field does not exist, the require () method looks for the index.js, Index.node, Index.json file under the package directory as the default entry

"Main": "./lib/livereload.js"

4. devdependencies--the modules needed for the development of the project. Some modules only need to be relied upon at development time. Configure this property to prompt subsequent developers of the package to install the dependency package. Analogy to the Dependencies field

  "Devdependencies": {    "coffee-script": ">= 1.8.0",    "Mocha": ">= 1.0.3",    "Request": ">= 2.9.203",    "should": ">= 0.6.3",    "Sinon": "^1.17.4"  } 

Packages in the Nodejs