本文由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主要有两个功能：
- 用来保存工程元数据。
- 还可以用来描述工程的依赖项。
为了深入理解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 <you.name@example.org>",
"contributors": [
{
"name": "Foo Bar",
"email": "foo.bar@example.com"
}
],
"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
依赖项。 而且是此包的依赖项。当其他人安装此包时，此属性所标记的依赖包将会被一并安装上。因此，软件包是否可以正常工作，依赖项就显得尤为重要了。
这里面：
- *和""都表示所有版本
- ~version表示大约是哪个版本，而^version表示兼容版本
- Version1-version2表示介于version1和version2之间的版本，包括version1和version2.
- Path/path/path表示依赖的是本地代码
- 也支持http和https远程代码
- Git，当然也支持。
devDependencies
和上面的依赖项功能差不多，但更多是在开发阶段和测试阶段标记有哪些依赖项。如果要使用这个属性的依赖项，那么就执行npm install –dev。
preferGlobal
只会在CLI中用到此属性，是用来标记此包是否支持全局安装的。
private
如果设为true了。那么此包就不会被发布到npm仓库中。
publishConfig
标记发布地址。这个地址不一定是npm官方仓库，也可以是team的私有仓库。只要能保存此包就可以。性质嘛，不重要。
license
许可证。虽然在国内，许可证不是很受人重视。但既然我们用了开源软件，就要遵守开源的游戏规则。该用什么许可就用什么许可。大多数情况下都是MIT许可。