nodejs npm package.json中文文档_node.js(4)
1.1.65版后，你可以仅仅用“user/foo-project”引用GitHub urls，比如：
{
"name": "foo",
"version": "0.0.0",
"dependencies": {
"express": "visionmedia/express"
}
}
devDependencies
如果有人计划在他们的程序中下载并使用你的模块，那么他们可能不想或者不需要去下载并构建你使用的外部测试或者文档框架。
在这种情况下，它最好把这些附属的项目列示在devDependencies hash中。
这些东西会在根目录执行npm link或者npm install的时候初始化，并可以像其他npm配置参数一样管理。详见npm-config(7)。
对于非特定平台的构建步骤，比如编译CoffeeScript或者其他语言到Javascript，用prepublish脚本去实现并把他放在devDependency中。
比如：
{ "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脚本会在publishing前运行，这样用户就不用自己去require来编译就能使用。并且在开发模式中（比如本地运行npm install）会运行这个脚本以便更好地测试。
peerDependencies
在一些场景中，如在一个host中不必须进行require时候，你想表现你的package与一个host工具或者库的兼容关键。这一般用来引用插件。尤其是你的模块可能要暴露一个特定的接口，并由host文档来预期和指定。
比如：
{
"name": "tea-latte",
"version": "1.3.5"
"peerDependencies": {
"tea": "2.x"
}
}
这能保证你的package可以只和tea的2.x版本一起初始化。npm install tea-latte可能会产生下面的依赖关系
├â”â” tea-latte@1.3.5
â””â”â” tea@2.2.0
试图初始化另一个有会冲突的依赖的插件将导致一个错误。因此，确保你的插件的需求约束越弱越好，而不要去把它锁定到一个特定的版本。
假设这个host遵守semver规范，只改变这个package的主版本会打破你的插件。因此，如果你在package中用过每个1.x版本，就用”^1.0″或者”1.x”来表示。如果你依赖于功能介绍1.5.2，用”>= 1.5.2 < 2″。
bundledDependencies
一组包名，他们会在发布的时候被打包进去。
拼成"bundleDependencies"（缺d）也可以。
optionalDependencies
如果一个依赖可用，但你希望在它安装错误的时候npm也能继续初始化，那么你可以把它放在optionalDependencies hash中。这是一个包名到版本或者url的map，就像dependencies hash一样。只是它运行错误。
处理缺乏依赖也是你的程序的责任。比如像这样：
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会覆盖dependencies中同名的项，所以通常比只放在一个地方好。
engines
