npm package.json 配置文件 - 推酷
npm package.json 配置文件
&name&: &studyangular&,
&version&: &0.0.0&,
&dependencies&: {},
&repository&: {},
&devDependencies&: {
&grunt&: &^0.4.5&,
&grunt-autoprefixer&: &^2.0.0&,
&grunt-concurrent&: &^1.0.0&,
&grunt-contrib-clean&: &^0.6.0&,
&grunt-contrib-compass&: &^1.0.0&,
&grunt-contrib-concat&: &^0.5.0&,
&grunt-contrib-connect&: &^0.9.0&,
&grunt-contrib-copy&: &^0.7.0&,
&grunt-contrib-cssmin&: &^0.12.0&,
&grunt-contrib-htmlmin&: &^0.4.0&,
&grunt-contrib-imagemin&: &^0.9.2&,
&grunt-contrib-jshint&: &^0.11.0&,
&grunt-contrib-uglify&: &^0.7.0&,
&grunt-contrib-watch&: &^0.6.1&,
&grunt-filerev&: &^2.1.2&,
&grunt-google-cdn&: &^0.4.3&,
&grunt-newer&: &^1.1.0&,
&grunt-ng-annotate&: &^0.9.2&,
&grunt-svgmin&: &^2.0.0&,
&grunt-usemin&: &^3.0.0&,
&grunt-wiredep&: &^2.0.0&,
&jshint-stylish&: &^1.0.0&,
&load-grunt-tasks&: &^3.1.0&,
&time-grunt&: &^1.0.0&
&engines&: {
&node&: &&=0.10.0&
&scripts&: {
&test&: &grunt test&
必须字段。
不要在name中包含js, node字样；
这个名字最终会是URL的一部分，命令行的参数，目录名，所以不能以点号或下划线开头；
这个名字可能在require()方法中被调用，所以应该尽可能短；
必须字段。
Description
可选字段，必须是字符串。
npm search
的时候会用到。
可选字段，字符串数组。
npm search
的时候会用到。
可选字段，
等带协议前缀的URL。
可选字段，问题追踪系统的URL或邮箱地址；
{ &url& :&/owner/project/issues&,
&email& :&&
可选字段。
如果是使用一个普遍的license，比如BSD-3-Clause或MIT，直接使用：
{ &license& : &BSD-3-Clause& }
Author, contributors
都是可选字段。author是一个人，contributors是一组人。
Author的格式如下：
{ &name& : &Barney Rubble&,
&email& : &&,
&url& : &/&
这种格式也可以：
&Barney Rubble && (/)&
可选字段，项目包含的一组文件。如果是文件夹，文件夹下的文件也会被包含。如果需要把某些文件不包含在项目中，添加一个”.npmignore”文件。这个文件和”gitignore”类似。
可选字段。这个字段的值是你程序主入口
。如果其他用户需要你的包，当用户调用require()方法时，返回的就是这个模块的导出（
可选字段。很多的包都会有执行文件需要安装到PATH中去。
这个字段对应的是一个Map，每个元素对应一个
{ 命令名：文件名 }
{ &bin& : { &npm& : &./cli.js& } }
Directories
用于指示包的目录结构：
Directories.lib
指示库文件的位置。
Directories.bin
和前面的bin是一样的，但如果前面已经有bin，那么这个就无效。
除了以上两个，还有Directories.doc& Directories.man & Directories.example。
Repository
可选字段。用于指示代码存放的位置。
&repository& :
{ &type& : &git&
, &url& : &/npm/npm.git&
&repository& :
{ &type& : &svn&
, &url& : &/svn/trunk/&
可选字段，object。Key是生命周期事件名，value是在事件点要跑的命令。参考npm-scripts。
可选字段，object。
Config对象中的值在
的整个周期中皆可用，专门用于给Scripts提供配置参数。
Dependencies
可选字段，指示当前包所依赖的其他包。
{ &dependencies& :
{ &foo& : &1.0.0 - 2.&
, &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& : &/asdf.tar.gz&
, &til& : &~1.2&
, &elf& : &~1.2.3&
, &two& : &2.x&
, &thr& : &3.3.x&
版本格式可以是下面任一种：
&大于这个版本
大于或等于这个版本
&非常接近这个版本
&与当前版本兼容
&X代表任意数字，因此1.2.1, 1.2.3等都可以
http://...
&Unix系统下使用的tarball的URL。
&任何版本都可以
任何版本都可以
version1 - version2
&=version1 &=version2
range1 || range2
&满足任意一个即可
devDependencies
可选字段。如果只需要下载使用某些模块，而不下载这些模块的测试和文档框架，放在这个下面比较不错。
peerDependencies
可选字段。兼容性依赖。如果你的包是插件，适合这种方式。
bundledDependencies
可选字段。发布包时同时打包的其他依赖。
optionalDependencies
可选字段。如果你想在某些依赖即使没有找到，或则安装失败的情况下，npm都继续执行。那么这些依赖适合放在这里。
可选字段。既可以指定node版本：
{ &engines& : {&node& : &&=0.10.3 &0.12& } }
也可以指定npm版本：
{ &engines& : {&npm& : &~1.0.20& } }
engineStrick
可选字段，布尔值。如果你肯定你的程序只能在制定的engine上运行，设置为true。
可选字段。指定模块可以在什么操作系统上运行：
&os& : [ &darwin&,&linux& ]
&os& : [ &!win32& ]
可选字段。指定CPU型号。
&cpu& : [ &x64&,&ia32& ]
&cpu& : [ &!arm&,&!mips& ]
preferGlobal
可选字段，布尔值。如果你的包是个命令行应用程序，需要全局安装，就可以设为true。
可选字段，布尔值。如果private为true，npm会拒绝发布。这可以防止私有repositories不小心被发布出去。
publishConfig
可选字段。发布时使用的配置值放这。
&scripts&:{&start&: &node server.js&}
如果你的包里有server.js文件，npm默认将执行：
node server.js
&scripts&:{&preinstall&:&node-gyp rebuild&}
如果包里有
binding.gyp，
preinstall命令时，使用node-gyp做编译。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致Node需要创建一个package.json文件
Node需要创建一个package.json文件
package.json是一个很重要的文件，用于管理模块的通用脚本、依赖等核心的配置数据。不论你是否对模块进行发布，或者简单地管理一个内部的项目，配置好一个package.json文件能够帮助你更好地进行开发。我们会讲到如何配置package.json以及使用npm来帮助你设置package。npm
init命令可以提供一个很方便的接口来一步步地配置package.json。我们在fastfib项目的根目录下执行这个命令：①模块的名称，发布时必填项，由于我们的项目目录名称为fastfib，所以默认为fastfib。②模块的版本。这也是必填项，强烈建议使用语义化的版本号（semver）。我们等一下再详细讲semver。我们从版本0.1.0开始③对模块比较详细的描述。这里使用简洁的一句话定义来描述我们这个模块。④模块的入口文件配置，模块加载时首先加载的文件。⑤测试的执行命令。配置之后可以使用npm test来执行对应的命令。考虑到我们的模块需要保证正确和速度，所以node test和node benchmark两者都需要运行。⑥存放代码的Git仓库的地址。如果你已经进行git仓库的初始化和添加了远程git地址，这个会自动帮你补全。⑦搜索模块时的关键字。⑧作者的信息！使用以下格式：[名称]&邮箱地址&([网站地址])。⑨这是一种软件发布许可证。需要了解更多关于package的配置项详情，可以使用npm help json来查看离线的帮助文档。当配置好默认的用户信息（$HOME/.npmrc），运行npm init会变得更加简单，默认的值都会帮助你先设置好。这里是可以配置的选项：使用了这些配置后，npm init不会再询问你author相关的信息，而直接帮你补全。当然，默认也使用MIT的许可证。
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
百家号 最近更新：
简介: 造物之前，必先造人。
作者最新文章npm配置-package.json - 简书
npm配置-package.json
npm的package.json的细节处理
这个文档告诉你，你的package.json文件需要什么。它实际上就是JSON，不只是一个js对象字面量
这篇文档里讲的受到的影响。
package.json里最重要的东西是name和version字段。如果没有他们，包都不能安装。name和version一起制定完全独立的。版本随着包修改而改变。
name是项目的称呼。
一些规则：
名字必须小于或者等于214个字符。包括scoped包的scope
不能以.或者_开头
新包里必须不能有大写字母
名字最终会成为url的一部分，一个命令行的参数，并且一个文件夹名。因此，名字里不能包含任何让URL非法的字符。
一些建议：
不要和Node的核心模块名相同
名字里不要带有js或者node。如果他是js，在package.json里使用engine指定
名字可能会是require()的参数，所以应该尽量短，但是要保证合理描述的前提
在创建钱应该先看看npm registry里有没有这个名字
在scope里，名字可以选择性的有前缀，比如:@myorg/mypackage. 查看
version必须能够被解析的。
description
帮助大家找到你的包，会在npm search里展示出来
是一个字符串数组，会帮助大家找到你的包，会在npm search里展示出来
作者的主页
注意：这和url不同。如果你放了一个url字段，那registry会认为它是重定向到在其他地方发布的包，然后spit at you.
Literally. Spit. I'm so not kidding.
项目问题跟踪的链接或者是上报问题的email。看起来是这样：
{ "url" : "/owner/project/issues"
,"email" : ""}
设置其中一个或者都设置都行。如果只提供一个url，bugs的值可以只是字符串，而不用是对象。
为包设置认证，这样大家就知道是怎么授权去使用的，和你对它的限制。
如果使用通用的认证比如BSD-2-Clause或者MIT，添加当前的SPDX认证：
{ "license" : "BSD-3-Clause" }
people fields:author，contributors
author是一个人。contributors就是一群人。person是一个带有name字段和可选的url和email的对象：
{ "name" : "Barney Rubble"
, "email" : ""
, "url" : "/"
或者使用缩写方式，npm会解析的:"myname myemail myurl"
"Barney Rubble && (/)"
email和url都是可选的。npm也设置了顶级的maintainers字段表明你的npm用户信息
files字段是项目包含的文件。如果数组里有文件夹，也会包含那个文件夹里的文件(除非有其他的忽略规则)
可以在根目录或者子目录里提供.npmignore来保证文件是否被引入，即使会是files array。.npmignore文件和.gitignore一样的工作方式。
下面的文件一定会包含，无视设置:
package.json
README(and its variants)
CHANGELOG(and its variants)
LICENSE/ LICENCE
相反地，一些文件总是会被忽略掉
.lock-wscript
.wafpickle-N
npm-debug.log
main字段是程序模块的主要入口。也就是说，如果你的包名是foo，并且有个用户安装了，然后使用require("foo")，那么main module的exports会被返回。
应该有一个module ID关联到根目录文件夹。
对于大多数模块，有一个main script就够了。
很多包有一个或者多个你想安装到PATH的可执行文件。npm让这个很容易(事实上，它是使用这个特性安装"npm"可执行)
为了使用这个，在package.json里提供bin字段，值为命令名字和本地文件名的map。一旦安装，npm会symlink这个文件到prefix/bin作为全局安装。或者./node_modules/.bin/作为局部安装
比如，myapp：
{ "bin" : { "myapp" : "./cli.js" } }
所以，当安装myapp时，会从cli.js脚本创建一个symlink到/usr/local/bin/myapp
如果有单个可执行，并且名字是package的名字，那么只用设置一个字符串就够了：
{ "name": "my-program"
, "version": "1.2.5"
, "bin": "./path/to/program" }
{ "name": "my-program"
, "version": "1.2.5"
, "bin" : { "my-program" : "./path/to/program" } }
指定单个文件或者多个文件名，让man程序查找
如果只有一个文件，那么安装就像从man &pkgname&的结果，无视真正的文件名：
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : "./man/doc.1"}
将会link到./man/doc.1文件，这样就是man foo的目标。
如果文件名不是从package name开始的，那么它是有前缀的：
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/bar.1" ]}
将会创建文件做man foo和man foo-bar
man文件以数字结尾，如果被压缩了，可以是.gz。数字决定那个man section the file is installed into.
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/foo.2" ]}
会为man foo和`man 2 foo创建入口
scripts属性是一个目录包含着在包的生命各个时期运行的脚本命令。key是生命周期的事件，value是在那个点运行的命令
repository
指定代码存放的位置。对想要贡献的人有帮助。如果git repo在GitHub上，那npm docs命令可以用来找到你.
如果是这样：
"repository" :
{ "type" : "git"
, "url" : "/npm/npm.git"
"repository" :
{ "type" : "svn"
, "url" : "/svn/trunk/"
这个URL应该是公开的能访问到的(可能是只读的)的指向没有任何修改的VCS程序的url。这个url不应该是一个html项目页面。
对于GitHub,GitHub gist, Bitbucket或者GitLab库,你可以使用相同的快捷语法使用npm安装：
"repository": "npm/npm"
"repository": "gist:11081aaa281"
"repository": "bitbucket:example/repo"
"repository": "gitlab:another/repo"
在持续升级的包脚本里使用config对象设置配置参数。比如，如果包邮以下：
{"name": "foo"
, "config" : {"port": "8080"}}
然后start命令里引用npm_package_config_port环境变量，那么用户可以通过npm config set foo:port 8001来重写
dependencies
Dependencies在一个简单对象里指向映射一个包名的范围。这个范围是一个有一个或者多个空格分隔的字符串描述器。Dependencies也可以是压缩包或者git URL.以前看nodejs只是看看API没有具体看这些细节，把别人的package.json拿来抄一抄，看字段也知道留下name、version、private、dependencies就好了，能方便地npm install部署就可以了，也没去深究。现在想在用起来在架构上面就遇到了很多问题。包括文件结构、管理、部署、重启&&昨天想先了解一下YO、GRUNT、Bower这一套东西正好看到了package.json的devDependencies字段。找到这个文档看，看着看着就看成了中文，也给大家送送福利。这样大家看起来就快多了。有什么问题希望大家快快拍砖。
package.json
本文档有所有package.json中必要的配置。它必须是真正的json，而不是js对象。
本文档中描述的很多行为都受npm-config(7)的影响。
npm会根据包内容设置一些默认值。
"scripts": {"start": "node server.js"}
如果包的根目录有server.js文件，npm会默认将start命令设置为node server.js。
"scripts":{"preinstall": "node-waf clean || 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是可选的。#号和空格开头的行会被忽略。
在package.json中_最_重要的就是name和version字段。他们都是必须的，如果没有就无法install。name和version一起组成的标识在假设中是唯一的。改变包应该同时改变version。
name是这个东西的名字。注意：
不要把node或者js放在名字中。因为你写了package.json它就被假定成为了js，不过你可以用"engine"字段指定一个引擎（见后文）。
这个名字会作为在URL的一部分、命令行的参数或者文件夹的名字。任何non-url-safe的字符都是不能用的。
这个名字可能会作为参数被传入require()，所以它应该比较短，但也要意义清晰。
在你爱上你的名字之前，你可能要去npm registry查看一下这个名字是否已经被使用了。
在package.json中_最_重要的就是name和version字段。他们都是必须的，如果没有就无法install。name和version一起组成的标识在假设中是唯一的。改变包应该同时改变version。
version必须能被解析，它被包在npm的依赖中。（要自己用可以执行npm install semver）
可用的&数字&或者&范围&见.
description
放简介，字符串。方便屌丝们在npm search中搜索。
关键字，数组、字符串。还是方便屌丝们在npm search中搜索。
项目官网的url。
注意：这和&url&_不_一样。如果你放一个&url&字段，registry会以为是一个跳转到你发布在其他地方的地址，然后喊你滚粗。
嗯，滚粗，没开玩笑。
你项目的提交问题的url和（或）邮件地址。这对遇到问题的屌丝很有帮助。
差不多长这样：
{ "url" : "/owner/project/issues"
, "email" : ""
你可以指定一个或者指定两个。如果你只想提供一个url，那就不用对象了，字符串就行。
如果提供了url，它会被npm bugs命令使用。
你应该要指定一个许可证，让人知道使用的权利和限制的。
最简单的方法是，假如你用一个像BSD或者MIT这样通用的许可证，就只需要指定一个许可证的名字，像这样：
{ "license" : "BSD" }
如果你又更复杂的许可条件，或者想要提供给更多地细节，可以这样:
"licenses" : [
{ "type" : "MyLicense"
, "url" : "/owner/project/path/to/license"
在根目录中提供一个许可证文件也蛮好的。
people fields: author, contributors
author是一个人。contributors是一堆人的数组。person是一个有name字段，可选的有url、email字段的对象，像这样：
{ "name" : "Barney Rubble"
, "email" : ""
, "url" : "/"
或者可以把所有的东西都放到一个字符串里，npm会给你解析：
"Barney Rubble && (/)
email和url在两种形式中都是可选的。
也可以在你的npm用户信息中设置一个顶级的maintainers字段。
files是一个包含项目中的文件的数组。如果命名了一个文件夹，那也会包含文件夹中的文件。（除非被其他条件忽略了）
你也可以提供一个.npmignore文件，让即使被包含在files字段中得文件被留下。其实就像.gitignore一样。
main字段配置一个文件名指向模块的入口程序。如果你包的名字叫foo，然后用户require("foo")，main配置的模块的exports对象会被返回。
这应该是一个相对于根目录的文件路径。
对于大多数模块，它是非常有意义的，其他的都没啥。
很多包都有一个或多个可执行的文件希望被放到PATH中。npm让妈妈再也不用担心了（实际上，就是这个功能让npm可执行的）。
要用这个功能，给package.json中的bin字段一个命令名到文件位置的map。初始化的时候npm会将他链接到prefix/bin（全局初始化）或者./node_modules/.bin/（本地初始化）。
比如，npm有：
{ "bin" : { "npm" : "./cli.js" } }
所以，当你初始化npm，它会创建一个符号链接到cli.js脚本到/usr/local/bin/npm。
如果你只有一个可执行文件，并且名字和包名一样。那么你可以只用一个字符串，比如：
{ "name": "my-program"
, "version": "1.2.5"
, "bin": "./path/to/program" }
结果和这个一样：
{ "name": "my-program"
, "version": "1.2.5"
, "bin" : { "my-program" : "./path/to/program" } }
指定一个单一的文件或者一个文件数组供man程序使用。
如果只提供一个单一的文件，那么它初始化后就是man &pkgname&的结果，而不管实际的文件名是神马，比如：
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : "./man/doc.1"
这样man foo就可以用到./man/doc.1文件了。
如果文件名不是以包名开头，那么它会被冠以前缀，下面的：
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/bar.1" ]
会为man foo和man foo-bar创建文件。
man文件需要以数字结束，然后可选地压缩后以.gz为后缀。The number dictates which man section the file is installed into.
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/foo.2" ]
会为man foo和man 2 foo创建。
directories
CommonJS&规范说明了几种方式让你可以用directorieshash标示出包得结构。如果看一下，你会看到有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 bywalking 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命令能找到你。
"repository" :
{ "type" : "git"
, "url" : "/isaacs/npm.git"
"repository" :
{ "type" : "svn"
, "url" : "/svn/trunk/"
URL应该是公开的（即便是只读的）能直接被未经过修改的版本控制程序处理的url。不应该是一个html的项目页面。因为它是给计算机看的。
&scripts&是一个由脚本命令组成的hash对象，他们在包不同的生命周期中被执行。key是生命周期事件，value是要运行的命令。
"config" hash可以用来配置用于包脚本中的跨版本参数。在实例中，如果一个包有下面的配置：
{ "name" : "foo"
, "config" : { "port" : "8080" } }
然后有一个&start&命令引用了npm_package_config_port环境变量，用户可以通过npm config set foo:port 8001来重写他。
参见&&和&。
dependencies
依赖是给一组包名指定版本范围的一个hash。这个版本范围是一个由一个或多个空格分隔的字符串。依赖还可以用tarball或者git URL。
**请不要将测试或过渡性的依赖放在dependencieshash中。**见下文的devDependencies。
version&必须完全和version一致
&version&必须比version大
&=version&同上
&version&同上
&=version&同上
~version&大约一样，见
1.2.x&1.2.0, 1.2.1, 等，但不包括1.3.0
http://...&见下文'依赖URL'
""&空，同*
version1 - version2&同&&=version1 &=version2.
range1 || range2&二选一。
git...&见下文'依赖Git URL'
user/repo&见下文'GitHub URLs'
比如下面都是合法的：
{ "dependencies" :
{ "foo" : "1.0.0 - 2."
, "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" : "/asdf.tar.gz"
, "til" : "~1.2"
, "elf" : "~1.2.3"
, "two" : "2.x"
, "thr" : "3.3.x"
可以指定一个tarball URL，这个tarball将在包被初始化的时候下载并初始化。
依赖Git URL
Git urls 可以是下面几种形式：
git:///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是可以被git checkout的任何tag、sha或者branch。默认为master。
GitHub URLs
1.1.65版后，你可以仅仅用&user/foo-project&引用GitHub urls，比如：
"name": "foo",
"version": "0.0.0",
"dependencies": {
"express": "visionmedia/express"
devDependencies
如果有人要使用你的模块，那么他们可能不需要你开发使用的外部测试或者文档框架。
在这种情况下，最好将这些附属的项目列在devDependencies中。
这些东西会在执行npm link或者npm install的时候初始化，并可以像其他npm配置参数一样管理。详见。
对于非特定平台的构建步骤，比如需要编译CoffeeScript，可以用prepublish脚本去实现，并把它依赖的包放在devDependency中。（译者注：prepublish定义了在执行npm publish的时候先行执行的脚本）
{ "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一样。只是它运行错误。
处理缺乏依赖也是你的程序的责任。比如像这样：
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中同名的项，所以通常比只放在一个地方好。
你可以指定工作的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" : [ "darwin", "linux" ]
你也可以用黑名单代替白名单，在名字前面加上&!&就可以了：
"os" : [ "!win32" ]
操作系统用process.platform来探测。
虽然没有很好地理由，但它是同时支持黑名单和白名单的。
如果你的代码只能运行在特定的cpu架构下，你可以指定一个：
"cpu" : [ "x64", "ia32" ]
就像os选项，你也可以黑一个架构：
"cpu" : [ "!arm", "!mips" ]
cpu架构用process.arch探测。
preferGlobal
如果包主要是需要全局安装的命令行程序，就设置它为true来提供一个warning给只在局部安装的人。
它不会真正的防止用户在局部安装，但如果它没有按预期工作它会帮助防止产生误会。
如果你设置"private": true，npm就不会发布它。
这是一个防止意外发布私有库的方式。如果你要确定给定的包是只发布在特定registry（如内部registry）的，用publishConfighash的描述来重写registry的publish-time配置参数。
publishConfig
这是一个在publish-time使用的配置集合。当你想设置tag或者registry的时候它非常有用，所以你可以确定一个给定的包没有打上&lastest&的tag或者被默认发布到全局的公开registry。
任何配置都可以被重写，但当然可能只有&tag&和&registry&与发布的意图有关。
参见有可以被重写的列表。
阅读(...) 评论() &
欢迎访问翱翔软件}