简介
本文档有所有package.json中必要的配置。它必须是真正的json，而不是js对象。
本文档中描述的很多行为都受npm-config(7)的影响。
默认值
npm会根据包内容设置一些默认值。
"scripts":{"preinstall": "node-waf clean || true; node-waf configure build"}
如果包的根目录有wscript文件，npm会默认将preinstall命令用node-waf进行编译。
"scripts":{"preinstall": "node-gyp rebuild"}
如果包的根目录有binding.gyp文件，npm会默认将preinstall命令用node-gyp进行编译。
"contributors": [...]
如果包的根目录有AUTHORS文件，npm会默认逐行按Name <email> (url)格式处理，邮箱和url是可选的。#号和空格开头的行会被忽略。
name
在package.json中最重要的就是name和version字段。他们都是必须的，如果没有就无法install。name和version一起组成的标识在假设中是唯一的。改变包应该同时改变version。
name是这个东西的名字。注意：
1.不要把node或者js放在名字中。因为你写了package.json它就被假定成为了js，不过你可以用”engine”字段指定一个引擎（见后文）。
2.这个名字会作为在URL的一部分、命令行的参数或者文件夹的名字。任何non-url-safe的字符都是不能用的。
3.这个名字可能会作为参数被传入require()，所以它应该比较短，但也要意义清晰。
4.在你爱上你的名字之前，你可能要去npm registry查看一下这个名字是否已经被使用了。http://registry.npmjs.org/
version
在package.json中最重要的就是name和version字段。他们都是必须的，如果没有就无法install。name和version一起组成的标识在假设中是唯一的。改变包应该同时改变version。
version必须能被node-semver解析，它被包在npm的依赖中。（要自己用可以执行npm install semver）
可用的“数字”或者“范围”见semver(7).
description
放简介，字符串。方便屌丝们在npm search中搜索。
keywords
关键字，数组、字符串。还是方便屌丝们在npm search中搜索。
homepage
项目官网的url。
注意：这和“url”不一样。如果你放一个“url”字段，registry会以为是一个跳转到你发布在其他地方的地址，然后喊你滚粗。
嗯，滚粗，没开玩笑。
bugs
你项目的提交问题的url和（或）邮件地址。这对遇到问题的屌丝很有帮助。
差不多长这样：
你可以指定一个或者指定两个。如果你只想提供一个url，那就不用对象了，字符串就行。
如果提供了url，它会被npm bugs命令使用。
license
你应该要指定一个许可证，让人知道使用的权利和限制的。
最简单的方法是，假如你用一个像BSD或者MIT这样通用的许可证，就只需要指定一个许可证的名字，像这样：
people fields: author, contributors
author是一个人。contributors是一堆人的数组。person是一个有name字段，可选的有url、email字段的对象，像这样：
也可以在你的npm用户信息中设置一个顶级的maintainers字段。
files
files是一个包含项目中的文件的数组。如果命名了一个文件夹，那也会包含文件夹中的文件。（除非被其他条件忽略了）
你也可以提供一个.npmignore文件，让即使被包含在files字段中得文件被留下。其实就像.gitignore一样。
main
main字段是一个模块ID，它是一个指向你程序的主要项目。就是说，如果你包的名字叫foo，然后用户安装它，然后require("foo")，然后你的main模块的exports对象会被返回。
这应该是一个相对于根目录的模块ID。
对于大多数模块，它是非常有意义的，其他的都没啥。
bin
很多包都有一个或多个可执行的文件希望被放到PATH中。npm让妈妈再也不用担心了（实际上，就是这个功能让npm可执行的）。
要用这个功能，给package.json中的bin字段一个命令名到文件位置的map。初始化的时候npm会将他链接到prefix/bin（全局初始化）或者./node_modules/.bin/（本地初始化）。
比如，npm有：
所以，当你初始化npm，它会创建一个符号链接到cli.js脚本到/usr/local/bin/npm。
如果你只有一个可执行文件，并且名字和包名一样。那么你可以只用一个字符串，比如：
结果和这个一样：
man
指定一个单一的文件或者一个文件数组供man程序使用。
如果只提供一个单一的文件，那么它初始化后就是man <pkgname>的结果，而不管实际的文件名是神马，比如：
这样man foo就可以用到./man/doc.1文件了。
如果文件名不是以包名开头，那么它会被冠以前缀，下面的：
man文件需要以数字结束，然后可选地压缩后以.gz为后缀。The number dictates which man section the file is installed into.
会为man foo和man 2 foo创建。
directories
CommonJS Packages规范说明了几种方式让你可以用directorieshash标示出包得结构。如果看一下npm's package.json，你会看到有directories标示出doc, lib, and man。
在未来，这个信息可能会被用到。
directories.lib
告诉屌丝们你的库文件夹在哪里。目前没有什么特别的东西需要用到lib文件夹，但确实是重要的元信息。
directories.bin
如果你指定一个“bin”目录，然后在那个文件夹中得所有文件都会被当做”bin”字段使用。
如果你已经指定了“bin”字段，那这个就无效。
directories.man
一个放满man页面的文件夹。贴心地创建一个“man”字段。
A folder that is full of man pages. Sugar to generate a “man” array by
walking the folder.
directories.doc
将markdown文件放在这里。最后，这些会被很好地展示出来，也许，某一天。
Put markdown files in here. Eventually, these will be displayed nicely,
maybe, someday.
directories.example
将事例脚本放在这里。某一天，它可能会以聪明的方式展示出来。
repository
指定你的代码存放的地方。这个对希望贡献的人有帮助。如果git仓库在github上，那么npm docs命令能找到你。
这样做：
scripts
“scripts”是一个由脚本命令组成的hash对象，他们在包不同的生命周期中被执行。key是生命周期事件，value是要运行的命令。
参见 npm-scripts(7)
config
“config” hash可以用来配置用于包脚本中的跨版本参数。在实例中，如果一个包有下面的配置：
参见 npm-config(7) 和 npm-scripts(7)。
dependencies
依赖是给一组包名指定版本范围的一个hash。这个版本范围是一个由一个或多个空格分隔的字符串。依赖还可以用tarball或者git URL。
请不要将测试或过渡性的依赖放在dependencieshash中。见下文的devDependencies。
详见semver(7).
1.version 必须完全和version一致
2.>version 必须比version大
3.>=version 同上
4.<version 同上
5.<=version 同上
6.~version 大约一样，见semver(7)
7.1.2.x 1.2.0, 1.2.1, 等，但不包括1.3.0
8.http://... 见下文'依赖URL'
9.* 所有
10."" 空，同*
11.version1 - version2 同 >=version1 <=version2.
12.range1 || range2 二选一。
13.git... 见下文'依赖Git URL'
14.user/repo 见下文'GitHub URLs'
15.比如下面都是合法的：
依赖URL
可以指定一个tarball URL，这个tarball将在包被初始化的时候下载并初始化。
依赖Git URL
Git urls 可以是下面几种形式：
GitHub URLs
1.1.65版后，你可以仅仅用“user/foo-project”引用GitHub urls，比如：
devDependencies
如果有人计划在他们的程序中下载并使用你的模块，那么他们可能不想或者不需要去下载并构建你使用的外部测试或者文档框架。
在这种情况下，它最好把这些附属的项目列示在devDependencies hash中。
这些东西会在根目录执行npm link或者npm install的时候初始化，并可以像其他npm配置参数一样管理。详见npm-config(7)。
对于非特定平台的构建步骤，比如编译CoffeeScript或者其他语言到Javascript，用prepublish脚本去实现并把他放在devDependency中。
比如：
prepublish脚本会在publishing前运行，这样用户就不用自己去require来编译就能使用。并且在开发模式中（比如本地运行npm install）会运行这个脚本以便更好地测试。
peerDependencies
在一些场景中，如在一个host中不必须进行require时候，你想表现你的package与一个host工具或者库的兼容关键。这一般用来引用插件。尤其是你的模块可能要暴露一个特定的接口，并由host文档来预期和指定。
比如：