nodejs npm package.json Chinese document_node.js-JS Tutorial-php.cn

Introduction

This document has all necessary configurations in package.json. It must be real json, not js object.

Much of the behavior described in this document is affected by npm-config(7).

Default value

npm will set some default values based on the package content.

Copy code The code is as follows:

"scripts": {"start": "node server.js" }
If there is a server.js file in the root directory of the package, npm will set the start command to node server.js by default.

"scripts":{"preinstall": "node-waf clean || true; node-waf configure build"}
If there is a wscript file in the root directory of the package, npm will compile the preinstall command with node-waf by default.

"scripts":{"preinstall": "node-gyp rebuild"}
If there is a binding.gyp file in the root directory of the package, npm will compile the preinstall command with node-gyp by default.

"contributors": [...]
If there is an AUTHORS file in the root directory of the package, npm will process it line by line in the format of Name (url) by default. Email and url are optional. Lines starting with # and spaces will be ignored.

name

The most important fields in package.json are the name and version fields. They are all required and cannot be installed without them. The identifier formed by name and version together is assumed to be unique. Changing the package should also change the version.

name is the name of this thing. Note:

1. Don’t put node or js in the name. Because you wrote package.json it is assumed to be js, but you can specify an engine using the "engine" field (see below).
2. This name will be used as part of the URL, command line parameter or folder name. Any non-url-safe characters are not allowed.
3. This name may be passed into require() as a parameter, so it should be short, but also clear in meaning.
4. Before you fall in love with your name, you may want to check the npm registry to see if the name is already in use. http://registry.npmjs.org/

version

version must be parsable by node-semver, which is included in npm dependencies. (If you want to use it yourself, you can execute npm install semver)

For available "numbers" or "ranges" see semver(7).

description

Put introduction, string. It is convenient for losers to search in npm search.

keywords

Keywords, arrays, strings. It is also convenient for losers to search in npm search.

homepage

The url of the project official website.

Note: This is not the same as "url". If you put a "url" field, the registry will think it is a jump to the address you published elsewhere, and then tell you to get lost.

Yeah, fuck me, no kidding.

bugs

The URL and/or email address of your project’s submission issue. This is helpful for diaosi who have problems.

It looks like this:

Copy code The code is as follows:

{ "url" : "http://github.com/owner/project/issues"

, "email" : "project@hostname.com"

}

You can specify one or two. If you just want to provide a url, then no object is needed, just a string.

If the url is provided, it will be used by the npm bugs command.

license

You should specify a license so that people know the rights and restrictions of use.

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

Copy code The code is as follows:

{ "license" : "BSD" }

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

Copy code The code is as follows:

"licenses" : [

{ "type" : "MyLicense"

, "url" : "http://github.com/owner/project/path/to/license"

}

]

It's also a good idea to provide a license file in the root directory.

people fields: author, contributors

The author is a person. contributors is an array of people. Person is an object with a name field, optional url, and email fields, like this:

Copy code The code is as follows:

{ "name" : "Barney Rubble"

, "email" : "b@rubble.com"

, "url" : "http://barnyrubble.tumblr.com/"

}

Or you can put everything into a string and npm will parse it for you:

Copy code The code is as follows:

"Barney Rubble (http://barnyrubble.tumblr.com/)

email and url are optional in both forms.

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

files

files is an array containing the files in the project. If a folder is named, the files in the folder will also be included. (unless ignored by other conditions)

You can also provide a .npmignore file so that files are retained even if they are included in the files field. In fact, it is just like .gitignore.

main

The main field is a module ID, which is a pointer to the main project of your program. That is, if the name of your package is foo, and the user installs it, and then require("foo"), then the exports object of your main module will be returned.

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

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

bin

Many packages have one or more executable files that they want to be placed in the PATH. npm lets mom no longer have to worry (in fact, it is this feature that makes npm executable).

To use this feature, give the bin field in package.json a map from the command name to the file location. During initialization, npm will link it to prefix/bin (global initialization) or ./node_modules/.bin/ (local initialization).

For example, npm has:

Copy code The code is as follows:

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

So, when you initialize npm, it will create a symlink to the cli.js script into /usr/local/bin/npm.

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

Copy code The code is as follows:

{ "name": "my-program"

, "version": "1.2.5"

, "bin": "./path/to/program" }

The result is the same as this:

Copy code The code is as follows:

{ "name": "my-program"

, "version": "1.2.5"

, "bin" : { "my-program" : "./path/to/program" } }

man

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

If only a single file is provided, then it will be the result of man after initialization, regardless of the actual file name, such as:

Copy code The code is as follows:

{ "name" : "foo"

, "version" : "1.2.3"

, "description" : "A packaged foo fooer for fooing foos"

, "main" : "foo.js"

, "man" : "./man/doc.1"

}

In this way, man foo can use the ./man/doc.1 file.

If the file name does not start with the package name, then it will be prefixed with the following:

Copy code The code is 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 be compressed with a .gz suffix. The number dictates which man section the file is installed into.

Copy code The code is 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 describes several ways that you can use directorieshash to indicate the structure of the package. If you look at npm's package.json, you'll see that there are directories labeled doc, lib, and man.

This information may be used in the future.

directories.lib

Tell the losers where your library folder is. There is nothing special about using the lib folder at the moment, but it is important meta information.

directories.bin

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

If you have specified the "bin" field, this will have no effect.

directories.man

A folder full of man pages. Carefully create a "man" field.
A folder that is full of man pages. Sugar to generate a “man” array by
walking the folder.

directories.doc

Put the markdown file here. Eventually, these will be shown nicely, perhaps, someday.
Put markdown files in here. Eventually, these will be displayed nicely,
maybe, someday.

directories.example

Put your example script here. One day, it might show up in a clever way.

repository

Specify where your code should be stored. This is helpful for those who wish to contribute. If the git repository is on github, the npm docs command can find you.

Do this:

Copy code The code is as follows:

"repository" :

{ "type" : "git"

, "url" : "http://github.com/isaacs/npm.git"

}

"repository" :

{ "type" : "svn"

, "url" : "http://v8.googlecode.com/svn/trunk/"

}

The URL should be a public (even read-only) URL that can be processed directly by an unmodified version control program. It should not be an html project page. Because it is for computers to see.

scripts

"scripts" is a hash object composed of script commands, which are executed during different life cycles of the package. The key is the life cycle event and the value is the command to be run.

See npm-scripts(7)

config

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

Copy code The code is as follows:

{ "name" : "foo"

, "config" : { "port" : "8080" } }

Then there is a "start" command that references the npm_package_config_port environment variable, and users can override it via npm config set foo:port 8001.

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

dependencies

A dependency is a hash that specifies a version range for a set of package names. The version range is a string separated by one or more spaces. Dependencies can also use tarballs or git URLs.

Please do not put test or transitional dependencies in the dependencieshash. See devDependencies below.

See semver(7) for details.

1.version must be completely consistent with version
2.>version must be larger than version
3.>=version Same as above
4. 5.<=version Same as above
6.~version is about the same, see semver(7)
7.1.2.x 1.2.0, 1.2.1, etc., but not including 1.3.0
8.http://... See 'Depend on URL' below
9.* All
10."" empty, same as *
11.version1 - version2 is the same as >=version1 <=version2.
12.range1 || range2 Choose one of the two.
13.git... See below 'Depends on Git URL'
14.user/repo See 'GitHub URLs' below
15. For example, the following are legal:

Copy code The code is 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"

}

}

Dependency URL

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

Depends on Git URL

Git urls can be in the following forms:

Copy code The code is 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 checked out by git. The default is master.

GitHub URLs

After version 1.1.65, you can just use "user/foo-project" to reference GitHub urls, such as:

Copy code The code is as follows:

{

"name": "foo",

"version": "0.0.0",

"dependencies": {

"express": "visionmedia/express"

}

}

devDependencies

If someone plans to download and use your module in their program, they may not want or need to download and build the external testing or documentation framework you use.

In this case, it is better to list these dependent projects in the devDependencies hash.

These things will be initialized when npm link or npm install is executed in the root directory, and can be managed like other npm configuration parameters. See npm-config(7) for details.

For non-platform-specific build steps, such as compiling CoffeeScript or other languages to Javascript, use a prepublish script to implement it and place it in devDependency.

For example:

Copy code The code is as follows:

{ "name": "ethopia-waza",

"description": "a delightfully fruity coffee variety",

"version": "1.2.3",

"devDependencies": {

"coffee-script": "~1.6.3"

},

"scripts": {

"prepublish": "coffee -o lib/ -c src/waza.coffee"

},

"main": "lib/waza.js"

}

The prepublish script will be run before publishing, so users don’t need to require it themselves to compile it before they can use it. And in development mode (such as running npm install locally) this script will be run for better testing.

peerDependencies

In some scenarios, such as when require is not required on a host, you want to show the compatibility key of your package with a host tool or library. This is generally used to reference plugins. In particular, your module may expose a specific interface that is expected and specified by the host document.

For example:

Copy code The code is as follows:

{

"name": "tea-latte",

"version": "1.3.5"

"peerDependencies": {

"tea": "2.x"

}

}

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

Copy code The code is as follows:

â”œâ”?â”? tea-latte@1.3.5

â””â”?â”? tea@2.2.0

Attempting to initialize another plugin that has conflicting dependencies will result in an error. Therefore, make sure your plugin's requirements are as weakly constrained as possible without locking it into a specific version.

Assuming this host adheres to the semver specification, just changing the major version of this package will break your plugin. Therefore, if you have used every 1.x version in a package, use "^1.0" or "1.x" to represent it. If you rely on feature introduction 1.5.2, use ">= 1.5.2 < 2".

bundledDependencies

A set of package names that will be included when released.

You can also spell it as "bundleDependencies" (missing d).

optionalDependencies

If a dependency is available, but you want npm to continue initializing even if it fails to install, you can put it in the optionalDependencies hash. This is a map of package names to versions or URLs, just like a dependencies hash. It just runs wrong.

Handling lack of dependencies is also your program's responsibility. For example, like this:

Copy code The code is 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 program ..

if (foo) {

foo.doFooThings()

}

optionalDependencies will override items with the same name in dependencies, so it's usually better than just putting them in one place.

engines

You can specify the version of the working node:

Copy code The code is as follows:

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

And, like dependencies, if you don't specify a version or specify "*" as the version, all versions of node will work.

If you specify an "engines" field, then npm will require node to be in it. If "engines" is omitted, npm will assume that it works on node.

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

Copy code The code is as follows:

{ "engines" : { "npm" : "~1.0.20" } }

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

engineStrict

If you are sure that your module will not run on node or npm other than the version you specified, you can set "engineStrict": true in the package.json file. 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 can easily get yourself into trouble. Consider this choice carefully. If people abuse it, it will be removed in future npm versions.

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

Copy code The code is as follows:

"os" : [ "darwin", "linux" ]

You can also use a blacklist instead of a whitelist, just add "!" in front of the name:

Copy code The code is as follows:

"os" : [ "!win32" ]

The operating system uses process.platform to detect.

Although there is no good reason, it supports both blacklist and whitelist.

cpu

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

Copy code The code is as follows:

"cpu" : [ "x64", "ia32" ]

Just like the os option, you can also hack an architecture:

Copy code The code is as follows:

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

The cpu architecture is detected using process.arch.

preferGlobal

If the package is primarily a command line program that needs to be installed globally, set this to true to provide a warning to people who only install it locally.

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

private

If you set "private": true, npm will not publish it.

This is a way to prevent accidental release of private libraries. If you want to ensure that a given package is published only in a specific registry (such as an internal registry), override the registry's publish-time configuration parameter with a publishConfighash description.

publishConfig

This is a configuration collection used at publish-time. This is useful when you want to set up a 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" may be relevant for publishing purposes.

See npm-config(7) for a list of things that can be overridden.