package.json参数详解

package.json必须是纯JSON的，而不仅仅是一个JavaScript对象字面量。

name和version

name和version字段是package.json文件中最重要的字段。这是必须的字段，如果你的npm包没有指定这两个字段，将无法被安装。name和version字段被假定组合成一个唯一的 标识符。包内容的更改和包版本的更改是同步的。

description

npm包的描述，description是一个字符串。它可以帮助人们在使用npm search时找到这个包。

keywords

npm包的关键字，keywords是一个字符串的数组。它可以帮助人们在使用npm search时找到这个包。

homepage

项目主页的url

bugs

改项目的issue跟踪页面或这报告issue的email地址。这对使用这个包遇到问题的用户会有帮助。

license

证书许可。SPDX表达式：
{ "license": "ISC" }
{ "license": "(MIT OR Apache-2.0)" }
通常我们不希望授权别人以任何形式使用的私有包或未发布包，可以这样写：
{ "license": "UNLICENSED"}或者设置"private": true

author, contributors

关于人的字段

files

files字段是一个被项目包含的文件名数组，如果你在里面放一个文件夹名，那么这个文件夹中的所有文件都会被包含进项目中(除非是那些在其他规则中被忽略的文件)。

main

main字段指定了模块的入口程序文件。就是说，如果你的模块名叫"foo"，用户安装了它，并且调用了 require("foo")，则这个main字段指定的模块的导出对象会被返回。
例如node_modules中引入的模块指定主入口文件

bin

许多包有一个或多个可执行文件希望被安装到系统路径。提供一个bin字段，它是一个命令名和本地文件名的映射。在安装时，如果是全局安装，npm将会使用符号链接把这些文件链接到prefix/bin，如果是本地安装，会链接到./node_modules/.bin/。

比如，要使用myapp作为命令时可以这么做：
{ "bin" : { "myapp" : "./cli.js" } }
当安装完毕myapp，npm会从cli.js文件创建一个到/usr/local/bin/myapp的符号链接(这使你可以直接在命令行执行myapp)。

man

指定一个单一的文件名或一个文件名数组来让man程序使用。如果只给man字段提供一个文件，则安装完毕后，它就是man 的结果，这和此文件名无关

directories

CommonJS Packages规范说明了几种你可以用directories对象来标示你的包结构的方法（lib、bin、man、doc、example）

repository

指明你的代码被托管在何处，这对那些想要参与到这个项目中的人来说很有帮助。如果git仓库在github上，用npm docs命令将会找到你。

scripts

scripts字段是一个由脚本命令组成的字典，这些命令运行在包的各个生命周期中。这里的键是生命周期事件名，值是要运行的命令。

config

config字段是一个对象，可以用来配置包脚本中的跨版本参数。

dependencies

dependencies字段是一个对象，它指定了依赖的包名和其版本范围的映射。版本范围是个有一个或多个空白分隔描述符的字符串。dependencies字段还可以用tarball或者git URL。

（请不要将测试或过渡性的依赖放到dependencies中）

devDependencies

如果有人计划在他们的项目中下载和使用你的模块，但他们可能并不想或并不需要你开发所使用的外部测试和文档框架。
在这种情况下，最好将这些附加的项放在devDependencies中。即开发模式下的依赖。

peerDependencies

在某些情况下，当一个主机无法require依赖包时，你会想要告诉它还有哪些工具或库与这个依赖包兼容。这通常被成为一个插件。尤其是在host文档中声明的模块会暴露一个特定的接口。

bundledDependencies

在发布包时，包名的数组会被打包进去。

optionalDependencies

如果一个依赖项可用，但希望在这个依赖项无法被找到或者安装时失败npm还能继续处理(不中断)，那么你可以把它放在optionalDependencies中。和dependencies一样，optionalDependencies是一个包名和版本号或url的映射。区别在于optionalDependencies中的依赖构建失败时不会导致npm整体安装失败。

但是你的程序依然有责任处理这种缺失的依赖项，例如

try{
    var foo=require('foo')
    var fooVersion=require('foo/package.json').version
}catch(er){
    foo=null
}if(notGoodFooVersion(fooVersion)){
    foo=null
}//..thenlaterinyourprogram..if(foo){
    foo.doFooThings()
}

optionalDependencies中的项会覆盖dependencies中的同名项，所以一个特定名字的项最好只出现在一个地方。

engines

你可以指定node的工作版本：
{ "engines" : { "node" : ">=0.10.3 <0.12" } }

os

可以指定模块运行的操作系统："os" : [ "darwin", "linux" ]
也可以使用操作系统黑名单来替代白名单，只要在前面加个'!'：
"os" : [ "!win32" ]

cpu

指明只能运行在特定的cpu架构上

preferGlobal

如果你的包是一个需要进行全局安装的命令行应用，需要设置preferGlobal为true，如果这个包被本地安装会报出一个警告。
这个选项并不会阻止用户本地安装这个包，但这么做确实能在包未按照预期被安装造成诸多麻烦时提供一些提示。

private

如果你在包的package.json中设置"private": true，则npm会拒绝发布它。这是防止私有包被以外发布的一种方法。

publishConfig

这是一个在publish-time时会用到的配置集合。当你想设置tag、registry或access时特别有用，所以你可以确保一个给定的包无法在没有被打上"latest"标记时就被发布到全局公共的registry。
任何配置都可以被覆盖，当然可能只有"tag", "registry"和"access"和发布意图有关。

---

总结心得

npm init基本能完成一个项目基础的构建。日常开发private:true然后管理好依赖，写好scripts基本就可以了。
但是如果要开发一个开源项目。peerDependencies、license、repository以及一些额外的bugs、homepage之类细化的东西都要熟悉了解。

---

参考

(译)package.json详解
Package.json 简介