Nodejs课堂笔记-第二课 package.json的作用

　　　　　　　　　　本文由Vikings(http://www.cnblogs.com/vikings-blog/) 原创，转载请标明.谢谢！

　　上节课，我们打造了一下IDE工具-web storm的显示界面。至少现在回到熟悉的sublime text界面了。这节课就开始正式学习nodejs了。

　　当我在web-storm创建了一个nodejs工程之后，首先浏览了一下工程结构，如下图所示：

　　Nodejs 的工程结构还是较为简单的。各个目录功能基本都能猜个八九不离十。但在最下面的package.json文件引起了我的注意。从名称上面来看应该是一个存储元数据的文件，到底是不是呢？我们打开它看一下：

　　从package.json内容中来看，其存储的不只有metedata，还有很多其它数据。例如版本号，依赖包等等。如此看来，package.json貌似很重要的样子。那么问题就来了:package.json到底是做什么的？

　　Nodejs官网给出的解释，package.json主要有两个功能：

1. 用来保存工程元数据。
2. 还可以用来描述工程的依赖项。

　　为了深入理解package.json，我们从nodejs官网下载一个完整的package.json示例，如下：

{

　　"name": "module-name",

　　"version": "10.3.1",

　　"description": "An example module to illustrate the usage of a package.json",

　　"author": "Your Name <[e-mail]>",

　　"contributors": [

　　　　{

　　　　　　"name": "Foo Bar",

　　　　　　"email": "[e-mail]"

　　　　}

　　],

　　"bin": {

　　　　　　"module-name": "./bin/module-name"

　　　　},

　　"scripts": {

　　　　"test": "vows --spec --isolate",

　　　　"start": "node index.js",

　　　　"prepublish": "coffee --bare --compile --output lib/foo src/foo/*.coffee"

　　},

　　"main": "lib/foo.js",

　　"repository": {

　　　　"type": "git",

　　　　"url": "https://github.com/nodejitsu/browsenpm.org"

　　},

　　"bugs": {

　　　　"url": "https://github.com/nodejitsu/browsenpm.org/issues"

　　},

　　"keywords": [

　　　　"nodejitsu",

　　　　"example",

　　　　"browsenpm"

　　],

　　"dependencies": {

　　　　"primus": "*",

　　　　"async": "~0.8.0",

　　　　"express": "4.2.x",

　　　　"winston": "git://github.com/flatiron/winston#master",

　　　　"bigpipe": "bigpipe/pagelet",

　　　　"plates": "https://github.com/flatiron/plates/tarball/master"

　　},

　　"devDependencies": {

　　　　"vows": "^0.7.0",

　　　　"assume": "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0",

　　　　"pre-commit": "*"

　　},

　　"preferGlobal": true,

　　"private": true,

　　"publishConfig": {

　　　　"registry": "https://your-private-hosted-npm.registry.nodejitsu.com"

　　},

　　"license": "MIT"

}

　　我们逐一看一下上述各个属性都是做什么的。

　　Name:

　　这个npm包的名称，使用时只需要注意名称为小写，同时保持唯一性。如果你决定将此包发布到npm官方仓库，那么此名称就是此包在仓库中的唯一标示。

　　Version：

　　这个包的版本号。默认风格是: 主版本.此版本.补丁版本。例如：10.3.1 。 这里面10是主版本，3是次版本，1是补丁版本。每次小的修改应该是补丁版本在变化。如果有大的代码或者功能变更，才会涉及到主版本号的变更。

　　Description：

　　这个包的描述信息，主要用来描述此包有哪些功能，已经如何使用。使用此属性的原则就是简单精炼。

　　author

　　没啥可说的。这就是作者的联系方式。 毕竟都是开源工具，如果其他人发现软件包有bug，或者其他问题。可以通过作者的联系方式，相互沟通确认。

　　contributors

　　这一栏是用于描述对此包有突出贡献的人及其联系方式。这个属性是一个对象数值，不用吝啬空间。有多少人就写多少人。

　　bin

　　此属性是用来标记软件包中可执行脚本位置的。当使用此属性时，需要输入脚本的相对路径。当在CLI中调用此包时，就会直接调用到此属性所标记的脚本。

　　script

　　script可以用来保存一些脚本。这些脚本在执行npm run {command name}或者npm run-script {command name}时就会运行。如果需要运行包内部的命令，直接使用命令名称就可以，而不必在敲入命令的相对路径。比如需要执行mocha时，直接写mocha就可以而不用写./node-modules/.bin/mocha了。

　　在上面的例子中，如果想要执行这个包的test脚本，那么当输入npm test时，就会调用到test所对应的命令了。

　　main

　　包的入口函数。用在代码调用此包时：require('{module name}')。 同其它语言一样，单单引入一个包并不会执行其内部的代码。所以当在其它代码中引入此包后，仍然需要通过手工写代码来实现调用。

　　repostitory

　　此属性用来标记此包源代码位置。如果你允许其它人修改你的代码，那么就提供源代码的位置。这样才会有更多的开发人员来提交代码分支，为代码做出贡献。 在上面的例子中，使用的是git仓库。但并不是只能使用git，任何源代码控制软件都可以。

　　bugs

　　只要是代码，就一定会存在bug。如果有人发现了bug，就可以提交到此属性所标记的地址。一方面是告诉作者，包里有bug。另外更重要的时提供了一个讨论的场合。作为程序员来说，沟通和讨论往往比闷头写代码更重要。

　　keywords

　　前面提到过，作者可以把此包提交到npm仓库中。此值所设定的就是其他人搜索的关键词。如果想让更多的人使用到此包，那么就尽可能的设定一些更贴合包功能的关键词吧。

　　Dependencies

　　依赖项。 而且是此包的依赖项。当其他人安装此包时，此属性所标记的依赖包将会被一并安装上。因此，软件包是否可以正常工作，依赖项就显得尤为重要了。

　　这里面：

1. *和""都表示所有版本
2. ~version表示大约是哪个版本，而^version表示兼容版本
3. Version1-version2表示介于version1和version2之间的版本，包括version1和version2.
4. Path/path/path表示依赖的是本地代码
5. 也支持http和https远程代码
6. Git，当然也支持。

　　devDependencies

　和上面的依赖项功能差不多，但更多是在开发阶段和测试阶段标记有哪些依赖项。如果要使用这个属性的依赖项，那么就执行npm install –dev。

　　preferGlobal

　　只会在CLI中用到此属性，是用来标记此包是否支持全局安装的。

　　private

　　如果设为true了。那么此包就不会被发布到npm仓库中。

　　publishConfig

　　标记发布地址。这个地址不一定是npm官方仓库，也可以是team的私有仓库。只要能保存此包就可以。性质嘛，不重要。

　　license

　　许可证。虽然在国内，许可证不是很受人重视。但既然我们用了开源软件，就要遵守开源的游戏规则。该用什么许可就用什么许可。大多数情况下都是MIT许可。