Nodejs npm Package.json Chinese document _node.js

Brief introduction

This document has the necessary configuration in all Package.json. It must be real json, not a JS object.

Many of the behaviors described in this document are affected by Npm-config (7).

Default value

NPM sets some default values based on the package content.

Copy Code code as follows:

"Scripts": {"Start": "Node Server.js"}
If the package's root directory has server.js files, NPM sets the start command to node Server.js by default.

"Scripts": {"Preinstall": "Node-waf Clean | | True Node-waf Configure Build "}
If the package's root directory has wscript files, NPM compiles the preinstall command by default with NODE-WAF.

"Scripts": {"Preinstall": "Node-gyp Rebuild"}
If the package's root directory has binding.gyp files, NPM compiles the preinstall command by default with Node-gyp.

"Contributors": [...]
If the package's root directory has authors files, NPM will default to line by name <email> (URL) format, and the mailboxes and URLs are optional. #号和空格开头的行会被忽略.

Name

The most important thing in Package.json is the name and version fields. They are all necessary and cannot be install if they are not. The identity made up of name and version is unique in the assumption. Changing the package should change version at the same time.

Name is this thing. Attention:

1. Do not put node or JS in the name. Because you wrote Package.json it is assumed to be JS, but you can specify an engine with the "Engine" field (see later).
2. This name will be used as a part of the URL, a command line parameter, or a folder name. Any non-url-safe characters are not available.
3. The name may be passed in as an argument to require (), so it should be shorter, but it should be very clear.
4. Before you fall in love with your name, you may want to go to NPM registry to see if the name is already in use. http://registry.npmjs.org/

Version

The most important thing in Package.json is the name and version fields. They are all necessary and cannot be install if they are not. The identity made up of name and version is unique in the assumption. Changing the package should change version at the same time.

Version must be able to be parsed by node-semver, which is wrapped in NPM's dependencies. (Use yourself to perform NPM install semver)

Available "number" or "range" see Semver (7).

Description

Put a brief, string. Make it easy for the cock to search in the NPM search.

Keywords

keywords, arrays, strings. Or is it convenient for the cock silk to search in the NPM search.

Homepage

The URL of the website of the project.

Note: This is not the same as "url". If you put a "url" field, registry will think it is a jump to the address you posted elsewhere, and then shout you roll rough.

Well, rough, no kidding.

Bugs

The URL and/or email address of your project submission question. This is very helpful to the problem of the cock silk.

Almost as long as this:

Copy Code code as follows:

{"url": "Http://github.com/owner/project/issues"
, "email": "project@hostname.com"
}

You can specify one or two. If you only want to provide a URL, then do not use the object, string on the line.

If a URL is provided, it is used by the NPM bugs command.

License

You should specify a license to let people know the rights and limitations of use.

The easiest way to do this is if you use a generic license like BSD or MIT, you just need to specify a license name, like this:

Copy Code code as follows:

{"License": "BSD"}

If you have more complex licensing conditions, or want to provide more details, you can do this:

Copy Code code as follows:

"Licenses": [
{' type ': ' Mylicense '
, "url": "Http://github.com/owner/project/path/to/license"
}
]

It's fine to provide a license file in the root directory.

People Fields:author, contributors

Author is a man. Contributors is a bunch of people's arrays. Person is an object that has a name field, optionally a URL, an email field, like this:

Copy Code code as follows:

{' name ': ' Barney rubble '
, "email": "b@rubble.com"
, "url": "http://barnyrubble.tumblr.com/"
}

Or you can put everything in a string, and NPM will give you an explanation:

Copy Code code as follows:

"Barney rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)

Email and URLs are optional in both forms.

You can also set up a top-level maintainers field in your NPM user information.

Files

The file is an array that contains the files in the project. If you name a folder, it also contains the files in the folder. (unless ignored by other criteria)

You can also provide a. npmignore file that allows files to be left even if they are included in the Files field. Actually, it's like. Gitignore.

Main

The main field is a module ID, which is a major item that points to your program. That is, if your package is named Foo, then the user installs it, then require ("foo"), and then your main module's exports object will be returned.

This should be a module ID relative to the root directory.

For most modules, it makes sense, and nothing else.

Bin

Many packages have one or more executable files that you want to be placed in path. NPM makes mom no longer have to worry (in fact, that's what NPM does).

To use this feature, give the Bin field in Package.json a map with a command name to the file location. NPM will link him to Prefix/bin (global initialization) or./node_modules/.bin/(local initialization) when initialized.

For example, NPM has:

Copy Code code as follows:

{' bin ': {' npm ': './cli.js '}}

So, when you initialize NPM, it creates a symbolic link to the Cli.js script to/USR/LOCAL/BIN/NPM.

If you have only one executable file, and the name is the same as the package name. So you can just use a string, such as:

Copy Code code as follows:

{' name ': ' My-program '
, "version": "1.2.5"
, "Bin": "./path/to/program"}

The result is the same as this:

Copy Code code as follows:

{' name ': ' My-program '
, "version": "1.2.5"
, "bin": {"My-program": "./path/to/program"}}

Mans

Specifies a single file or an array of files for use by the man program.

If only a single file is provided, then it is initialized with the results of man <pkgname>, regardless of the actual filename is God horse, such as:

Copy Code code as follows:

{' name ': ' foo '
, "version": "1.2.3"
, "description": "A packaged foo fooer for fooing Foos"
, "main": "Foo.js"
, "Man": "./man/doc.1"
}

So that man Foo can use the./man/doc.1 file.

If the filename does not start with the package name, it is prefixed with the following:

Copy Code code as follows:

{' name ': ' foo '
, "version": "1.2.3"
, "description": "A packaged foo fooer for fooing Foos"
, "main": "Foo.js"
, "Man": ["./man/foo.1", "./man/bar.1"]
}

Files will be created for man Foo and man Foo-bar.

The man file needs to end with a number and then optionally compress to the. gz suffix. The number dictates which mans section the file is installed into.

Copy Code code as follows:

{' name ': ' foo '
, "version": "1.2.3"
, "description": "A packaged foo fooer for fooing Foos"
, "main": "Foo.js"
, "Man": ["./man/foo.1", "./man/foo.2"]
}

will be created for man Foo and Man 2 foo.

Directories

The COMMONJS packages specification illustrates several ways in which you can use Directorieshash to mark a package structure. If you look at NPM's Package.json, you'll see a directories labeled Doc, Lib, and man.

In the future, this information may be used.

Directories.lib

Tell the cock where your library folder is. There is nothing special at the moment that needs to be used in the Lib folder, but it is really important meta information.

Directories.bin

If you specify a "bin" directory, then all files in that folder will be used as "bin" fields.

If you have specified a "Bin" field, this is not valid.

Directories.man

A folder full of man pages. Create a "man" field with a sweet heart.
A folder is all man pages. Sugar to generate a "mans" array by
Walking the folder.

Directories.doc

Put the markdown file here. Finally, these will be well displayed, perhaps, one day.
Put markdown files with here. Eventually, these would be displayed nicely,
Maybe, someday.

Directories.example

Put the case script here. One day, it may be shown in a clever way.

Repository

Specify where your code is stored. This is helpful to those who wish to contribute. If the Git warehouse is on the GitHub, then NPM docs commands to find you.

Do this:

Copy Code code as follows:

"Repository":
{' type ': ' Git '
, "url": "Http://github.com/isaacs/npm.git"
}
"Repository":
{' type ': ' SVN '
, "url": "http://v8.googlecode.com/svn/trunk/"
}

URLs should be public (that is, read-only) URLs that can be processed directly by the unmodified version of the program. Should not be an HTML project page. Because it is for the computer to see.

Scripts

"Scripts" is a hash object made up of script commands that are executed in different life cycles of the package. Key is a lifecycle event, value is the command to run.

See also Npm-scripts (7)

Config

The "config" hash can be used to configure the cross version parameters in the package script. In the instance, if a package has the following configuration:

Copy Code code as follows:

{' name ': ' foo '
, "config": {"port": "8080"}}}

Then there is a "start" command that references the NPM_PACKAGE_CONFIG_PORT environment variable, and the user can rewrite it via the NPM config set Foo:port 8001来.

See also Npm-config (7) and npm-scripts (7).

Dependencies

Dependency is a hash that specifies a version range for a set of package names. This version range is a string separated by one or more spaces. Dependencies can also be used with tarball or Git URLs.

Do not place test or bridging dependencies in Dependencieshash. See below for devdependencies.

See Semver (7) for details.

1.version must be completely consistent with version
2.>version must be larger than version
3.>=version ditto
4.<version ditto
5.<=version ditto
6.~version about the same, see Semver (7)
7.1.2.x 1.2.0, 1.2.1, etc., but excluding 1.3.0
8.http://... See below ' dependency url '
9.* All
10. "" Empty, Same *
11.version1-version2 with >=version1 <=version2.
12.range1 | | Range2 two choose one.
13.git ... See below ' rely on git URL '
14.user/repo See "GitHub URLs" below
15. For example, the following are all legal:

Copy Code code as follows:

{"Dependencies":
{"Foo": "1.0.0-2.9999.9999"
, "bar": ">=1.0.2 <2.1.2"
, "Baz": ">1.0.2 <=2.3.4"
, "Boo": "2.0.1"
, "Qux": "<1.0.0 | | >=2.3.1 <2.4.5 | | >=2.5.2 <3.0.0 "
, "ASD": "Http://asdf.com/asdf.tar.gz"
, "til": "~1.2"
, "Elf": "~1.2.3"
, "two": "2.x"
, "THR": "3.3.x"
}
}

Dependent URL

You can specify a tarball URL that will be downloaded and initialized when the package is initialized. tarball

Rely on Git URL

Git URLs can be in the following ways:

Copy Code code as follows:

Git://github.com/user/project.git#commit-ish
Git+ssh://user@hostname:project.git#commit-ish
Git+ssh://user@hostname/project.git#commit-ish
Git+http://user@hostname/project/blah.git#commit-ish
Git+https://user@hostname/project/blah.git#commit-ish

Commit-ish is any tag, SHA, or branch that can be checkout by Git. The default is master.

GitHub URLs

After the 1.1.65 version, you can simply use "User/foo-project" to refer to GitHub URLs, such as:

Copy Code code as follows:

{
' Name ': ' foo ',
"Version": "0.0.0",
"Dependencies": {
"Express": "Visionmedia/express"
}
}

Devdependencies

If someone plans to download and use your modules in their programs, they may not want to or need to download and build the external test or document framework that you are using.

In this case, it is best to list the attached items in the devdependencies hash.

These things are initialized at the root directory of NPM link or npm install, and can be managed like other NPM configuration parameters. See Npm-config (7) for details.

For platform-neutral building steps, such as compiling coffeescript or other languages to JavaScript, use the Prepublish script to implement and put him in devdependency.

Like what:

Copy Code code as follows:

{' name ': ' Ethopia-waza ',
"description": "A delightfully fruity coffee varietal",
"Version": "1.2.3",
"Devdependencies": {
"Coffee-script": "~1.6.3"
},
"Scripts": {
"Prepublish": "Coffee-o lib/-C Src/waza.coffee"
},
"Main": "Lib/waza.js"
}

Prepublish scripts run before publishing, so that users do not have to require to compile them. And in development mode, such as running NPM install locally, this script is run to better test.

Peerdependencies

In some scenarios, such as when you do not have to require in a host, you want to show that your package is key to the compatibility of a host tool or library. This is typically used to refer to plug-ins. In particular, your module may have to expose a specific interface and be expected and specified by the host document.

Like what:

Copy Code code as follows:

{
"Name": "Tea-latte",
"Version": "1.3.5"
"Peerdependencies": {
"Tea": "2.x"
}
}

This ensures that your package can be initialized with only the 2.x version of tea. NPM install Tea-latte may produce the following dependencies

Copy Code code as follows:

â "œâ"? â "? tea-latte@1.3.5
â "â"? â "? tea@2.2.0

Attempting to initialize another dependent plug-in with conflicting dependencies will result in an error. Therefore, make sure that your plug-in's requirements are as weak as possible, rather than locking it into a specific version.

Assuming this host complies with the SEMVER specification, changing only the main version of this package will break your plugin. So, if you use each 1.x version in the package, it is represented by "^1.0″ or 1.x". If you rely on feature introduction 1.5.2, use ">= 1.5.2 < 2″."

Bundleddependencies

A set of package names that they will be packaged in when they are released.

Spell "Bundledependencies" (missing D) can also be.

Optionaldependencies

If a dependency is available, but you want NPM to continue initializing when it installs incorrectly, you can put it in the optionaldependencies hash. This is a map of package name to version or URL, just like dependencies hash. It just runs wrong.

Dealing with a lack of dependency is also the responsibility of your program. Like this:

Copy Code code as follows:

try {
var foo = require (' foo ')
var fooversion = require (' Foo/package.json '). Version
catch (er) {
Foo = null
}
if (Notgoodfooversion (fooversion)) {
Foo = null
}
// .. Then later in your.
if (foo) {
Foo.dofoothings ()
}

Optionaldependencies overrides an item with the same name in dependencies, so it's usually better than just putting it in one place.

Engines

You can specify the version of the node for the work:

Copy Code code as follows:

{' engines ': {' node ': ' >=0.10.3 <0.12 '}}

And, like Dependensies, if you don't specify a version or specify "*" as the version, then all versions of node are OK.

If you specify a "engines" field, NPM will need node in it, and NPM will assume it works on node if "engines" is omitted.

You can also use the "Engines" field to specify which NPM version can better initialize your program, such as:

Copy Code code as follows:

{"Engines": {"NPM": "~1.0.20"}}

Remember, this field is only a suggested value unless the user sets the engine-strict tag.

Enginestrict

If you are certain that your module will not run on node or NPM other than your specified version, you can set "Enginestrict" in the Package.json file: True. It overrides the user's engine-strict settings.

Don't do this unless you are very, very sure. If your engines hash is overly restrictive, you may easily get yourself into a dilemma. Consider this option with caution. If you abuse it, it will be removed later in the NPM version.

Os

You can specify which operating systems your module will run on:

Copy Code code as follows:

"OS": ["Darwin", "Linux"]

You can also use a blacklist instead of a whitelist, preceded by the name "!" It's OK:

Copy Code code as follows:

"OS": ["!win32"]

The operating system uses Process.platform to detect.

Although not well justified, it is also supported on both the blacklist and whitelist.

Cpu

If your code can only run under a specific CPU architecture, you can specify a:

Copy Code code as follows:

"CPU": ["x64", "IA32"]

Like OS options, you can also hack a schema:

Copy Code code as follows:

"CPU": ["!arm", "!mips"]

CPU architecture is probed with Process.arch.

Preferglobal

If the package is primarily a command-line program that requires global installation, set it to true to provide a warning to people who are only installed locally.

It won't really prevent users from installing locally, but if it doesn't work as expected it will help prevent misunderstandings.

Private

If you set "private": TRUE,NPM will not publish it.

This is a way to prevent accidental publishing of private libraries. If you want to determine that a given package is published only in a specific registry (such as an internal registry), rewrite the registry publish-time configuration parameters with a publishconfighash description.

Publishconfig

This is a collection of configurations that are used in publish-time. It is useful when you want to set up tag or registry, so you can make sure that a given package is not tagged with "lastest" or is published to the global public registry by default.

Any configuration can be overridden, but of course only "tag" and "registry" are related to the intended publication.

See Npm-config (7) For a list that can be overridden.