Nodejsnpmpackage. json Chinese Document _ node. js

This article mainly introduces the nodejsnpmpackage. json Chinese document. Many of the behaviors described in this document are affected by npm-config (7). For more information, see Introduction

This document provides all necessary configurations in package. json. It must be a real json object instead of a js object.

Many of the actions described in this document are affected by npm-config (7.

Default Value

Npm sets some default values based on the package content.

The Code is as follows:

"Scripts": {"start": "node server. js? 1.1.9 "}
If the root directory of the package contains the server. js file, npm sets the start command to node server. js by default.

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

"Scripts": {"preinstall": "node-gyp rebuild "}
If the package root directory contains the binding. gyp file, npm will compile the preinstall command with node-gyp by default.

"Contributors": [...]
If the root directory of the package contains the AUTHORS file, npm defaults to line by Name (Url) format processing, mailbox and url are optional. # The line starting with "#" and "space" is ignored.

Name

The name and version fields are the most important in package. json. They are all required. If not, they cannot install. The identifier composed of name and version is unique in the hypothesis. Change the version of the package at the same time.

Name is the name of this item. Note:

1. Do not put node or js in the name. Because you write package. json, it is assumed to be JavaScript, but you can use the "engine" field to specify an engine (see the following article ).
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 unavailable.
3. This name may be passed into require () as a parameter, so it should be short but clear.
4. Before you fall in love with your name, you may go to npm registry to check whether the name has been used. Http://registry.npmjs.org/

Version

The name and version fields are the most important in package. json. They are all required. If not, they cannot install. The identifier composed of name and version is unique in the hypothesis. Change the version of the package at the same time.

The version must be parsed by node-semver, which is included in the npm dependency. (Run npm install semver on your own)

For available "Numbers" or "ranges", see semver (7 ).

Description

Put the introduction, String. This makes it easy for you to search in npm search.

Keywords

Keyword, array, String. It is also convenient for you to search in npm search.

Homepage

The url of the project's official website.

Note: This is different from "url. If you put a "url" field, the registry will assume that it is an address that jumps to the address you posted elsewhere, and then calls you rough.

Well, it's no joke.

Bugs

The url and/or email address of your project's submission question. This is very helpful for the problem.

The length is almost as follows:

The Code is 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, you don't need to use an object. You can just use a string.

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

License

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

The simplest way is to use a license that is generic like BSD or MIT, you only need to specify a license name, like this:

The Code is as follows:

{"License": "BSD "}

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

The Code is as follows:

"Licenses ":[
{"Type": "MyLicense"
, "Url": "http://github.com/owner/project/path/to/license"
}
]

It is good to provide a license file in the root directory.

People fields: author, contributors

Author is a person. Contributors is an array of people. Person is an object with a name field and an optional url or email field, like this:

The Code is 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 parse it for you:

The Code is as follows:

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

Email and url are both optional.

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

Files

Files is an array containing files in the project. If a folder is named, it will also contain files in the folder. (Unless it is ignored by other conditions)

You can also provide a. npmignore file to keep the file even if it is included in the files field. Actually, it's like. gitignore.

Main

The main field is a module ID, which is a main project pointing to your program. That is to say, if your package is named foo, then 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 is very meaningful, and nothing else.

Bin

Many packages have one or more executable files that you want to put in the PATH. Npm makes Mom no longer have to worry about it (in fact, this function makes npm executable ).

Use this function to map the bin field in package. json 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:

The Code is as follows:

{"Bin": {"npm": "./cli. js? 1.1.9 "}}

Therefore, when you initialize npm, it will create a symbolic link to the cli. js script to/usr/local/bin/npm.

If you only have one executable file with the same name as the package name. You can use only one string, for example:

The Code is as follows:

{"Name": "my-program"
, "Version": "1.2.5"
, "Bin": "./path/to/program "}

The result is the same as this:

The Code is as follows:

{"Name": "my-program"
, "Version": "1.2.5"
, "Bin": {"my-program": "./path/to/program "}}

Man

Specifies a single file or an array of files for man programs.

If only one single file is provided, it is called man after initialization. Regardless of the actual file name, for example:

The Code is as follows:

{"Name": "foo"
, "Version": "1.2.3"
, "Description": "A packaged foo fooer for fooing foos"
, "Main": "foo. js? 1.1.9"
, "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, it is prefixed with the following:

The Code is as follows:

{"Name": "foo"
, "Version": "1.2.3"
, "Description": "A packaged foo fooer for fooing foos"
, "Main": "foo. js? 1.1.9"
, "Man": ["./man/foo.1", "./man/bar.1"]
}

Creates a file for man foo and man foo-bar.

The manfile suffix is numeric, and can be compressed with a suffix of .gz. The number dictates which man section the file is installed.

The Code is as follows:

{"Name": "foo"
, "Version": "1.2.3"
, "Description": "A packaged foo fooer for fooing foos"
, "Main": "foo. js? 1.1.9"
, "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 for you to use directorieshash to mark the package structure. If you look at npm's package. json, you will see directories indicating doc, lib, and man.

This information may be used in the future.

Directories. lib

Tell you where your library folder is. At present, there is nothing special to use the lib folder, but it is indeed an important metadata.

Directories. bin

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

If you have already specified the "bin" field, this is invalid.

Directories. man

A folder filled with man pages. Create a "man" field.
A folder that is full of man pages. Sugar to generate a "man" array
Walking the folder.

Directories.doc

Put the markdown file here. Finally, these will be well presented, maybe, one day.
Put markdown files in here. Eventually, these will be displayed nicely,
Maybe, someday.

Directories. example

Put the case script here. One day, it may be displayed in a smart way.

Repository

Specifies where your code is stored. This helps those who wish to contribute. If the git repository is on github, the npm docs command can find you.

In this way:

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 public (even read-only) URLs that can be directly processed by the version control program without modification. It should not be an html project page. Because it is for computers.

Scripts

"Scripts" is a hash object consisting of script commands, which are executed in different lifecycles of the package. Key is a lifecycle event, and value is a command to run.

See npm-scripts (7)

Config

"Config" hash can be used to configure cross-version parameters used in the package script. In the instance, if a package has the following Configuration:

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. You can rewrite it through npm config set foo: port 8001.

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

Dependencies

Dependency is a hash that specifies the version range for a group of package names. This version range is a string separated by one or more spaces. You can also use tarball or git URL for dependencies.

Do not place testing or transitional dependencies in dependencieshash. See the following devDependencies.

For details, see semver (7 ).

1. The version must be completely consistent with the version.
2.> version must be larger than version.
3.> = version same as above
4. 5. <= version same as above
6 .~ The version is about the same. See semver (7)
7.1.2.x 1.2.0, 1.2.1, and so on, excluding 1.3.0
8. http: //... see the following section 'dependency url'
9. * All
10. "" null, same *
11. version1-same as version2> = version1 <= version2.
12. range1 | select either range2 or range1.
13. git... see 'dependent Git url' below'
14. For details about user/repo, see 'github urls'
15. For example, the following are legal:

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"
}
}

Dependent URL

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

Dependent on Git URL

Git urls can be in the following forms:

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 checkout by git. The default value is master.

GitHub URLs

After version 1.1.65, you can use "user/foo-project" to reference GitHub urls, for example:

The Code is 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 or do not need to download and build the external test or document framework you are using.

In this case, it is best to list these affiliated 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. For details, see npm-config (7 ).

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

For example:

The Code is as follows:

{"Name": "etemediia-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? 1.1.9"
}

The prepublish script runs before Hing, so that you do not need to compile and use it by yourself. In the Development Mode (such as running npm install locally), the script is run to better test the script.

PeerDependencies

In some scenarios, for example, when require is not required for a host, you want to demonstrate the key to compatibility of your package with a host tool or library. This is generally used to reference plug-ins. In particular, your module may expose a specific interface, which is expected and specified by the host document.

For example:

The Code is as follows:

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

This ensures that your package can be initialized only with tea 2.x. Npm install tea-latte may produce the following dependency

The Code is as follows:

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

Attempting to initialize another conflicting dependency plug-in will cause an error. Therefore, make sure that the demand constraints of your plug-in are weaker and better, instead of locking it into a specific version.

Assume that this host complies with the semver specification. Changing the main version of this package will break your plug-in. Therefore, if you have used each 1.x version in a package, it is represented by "^ 1.0" or "1. x. If you are dependent on function introduction 1.5.2, use "> = 1.5.2 <2 ″.

BundledDependencies

A group of package names will be packaged during release.

You can also create a bundleDependencies.

OptionalDependencies

If a dependency is available, but you want npm to continue initialization when it is installed incorrectly, you can put it in optionalDependencies hash. This is a map with the package name to the version or url, just like dependencies hash. It is only a running error.

Dealing with a lack of dependencies is also the responsibility of your program. For example:

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 overwrite items with the same name in dependencies, so it is better to put them in only one place.

Engines

You can specify the version of the working node:

The Code is as follows:

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

In addition, like dependensies, if you do not specify a version or specify "*" as a version, all vertices can.

If a "engines" field is specified, npm needs the node to be in it. If "engines" is omitted, npm assumes that it works on the node.

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

The Code is as follows:

{"Engines": {"npm ":"~ 1.0.20 "}}

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

EngineStrict

If you are sure that your module will not run on a node or npm other than your specified version, you can set "engineStrict": true in the package. json file. It will overwrite your engine-strict settings.

Do not do this unless you are very sure. If your engines hash is too restrictive, you may easily get yourself into a dilemma. Consider this option with caution. If you misuse it, it will be deleted in future npm versions.

OS

You can specify the operating systems in which your module runs:

The Code is as follows:

"OS": ["darwin", "linux"]

You can also use the blacklist to replace the White List and add "!" before the name. You can:

The Code is as follows:

"OS ":["! Win32 "]

The operating system uses process. platform for testing.

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

Cpu

If your code can only run in a specific cpu architecture, you can specify one:

The Code is as follows:

"Cpu": ["x64", "ia32"]

Like the OS option, you can also blacklist an architecture:

The Code is as follows:

"Cpu ":["! Arm ","! Mips "]

Cpu architecture is tested using process. arch.

PreferGlobal

If the package is mainly a command line program that needs to be installed globally, set it to true to provide a warning for the local installer only.

It does not really prevent users from local installation, but it will help prevent misunderstandings if it does not work as expected.

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 confirm that the given package is only published in a specific registry (such as an internal registry), use the description of publishConfighash to override the publish-time Configuration Parameter of the registry.

PublishConfig

This is a collection of configurations used in publish-time. It is very useful when you want to set a tag or registry, so you can determine that a given package does not have a "lastest" tag or is released to a global public registry by default.

Any configuration can be rewritten, but of course only "tag" and "registry" may be related to the publishing intent.

See npm-config (7) for a list that can be rewritten.