假设这个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
你可以指定工作的node的版本：
复制代码 代码如下:
{ "engines" : { "node" : ">=0.10.3 <0.12" } }
并且，像dependensies一样，如果你不指定版本或者指定“*”作为版本，那么所有版本的node都可以。
如果指定一个“engines”字段，那么npm会需要node在里面，如果“engines”被省略，npm会假定它在node上工作。
你也可以用“engines”字段来指定哪一个npm版本能更好地初始化你的程序，如：
复制代码 代码如下:
{ "engines" : { "npm" : "~1.0.20" } }
记住，除非用户设置engine-strict标记，这个字段只是建议值。
engineStrict
如果你确定你的模块一定不会运行在你指定版本之外的node或者npm上，你可以在package.json文件中设置"engineStrict":true。它会重写用户的engine-strict设置。
除非你非常非常确定，否则不要这样做。如果你的engines hash过度地限制，很可能轻易让自己陷入窘境。慎重地考虑这个选择。如果大家滥用它，它会再以后的npm版本中被删除。
os
你可以指定你的模块要运行在哪些操作系统中：
复制代码 代码如下:
"os" : [ "darwin", "linux" ]
你也可以用黑名单代替白名单，在名字前面加上“!”就可以了：
复制代码 代码如下:
"os" : [ "!win32" ]
操作系统用process.platform来探测。
虽然没有很好地理由，但它是同时支持黑名单和白名单的。
cpu
如果你的代码只能运行在特定的cpu架构下，你可以指定一个：
复制代码 代码如下:
"cpu" : [ "x64", "ia32" ]
就像os选项，你也可以黑一个架构：
复制代码 代码如下:
"cpu" : [ "!arm", "!mips" ]
cpu架构用process.arch探测。
preferGlobal
如果包主要是需要全局安装的命令行程序，就设置它为true来提供一个warning给只在局部安装的人。
它不会真正的防止用户在局部安装，但如果它没有按预期工作它会帮助防止产生误会。
private
如果你设置"private": true，npm就不会发布它。
这是一个防止意外发布私有库的方式。如果你要确定给定的包是只发布在特定registry（如内部registry）的，用publishConfighash的描述来重写registry的publish-time配置参数。
publishConfig
这是一个在publish-time使用的配置集合。当你想设置tag或者registry的时候它非常有用，所以你可以确定一个给定的包没有打上“lastest”的tag或者被默认发布到全局的公开registry。
任何配置都可以被重写，但当然可能只有“tag”和“registry”与发布的意图有关。
参见npm-config(7)有可以被重写的列表。
您可能感兴趣的文章: