{ "name": "test", "version": "0.1.0", "description": "A testing package", "author": "A messed author <messed@example.com>", "dependencies": { "express": "1.x.x", "ejs": "0.4.2", "redis": ">= 0.6.7" }, "devDependencies": { "vows": "0.5.x" }, "main": "index", "bin": { "test": "./bin/test.js" }, "scripts": { "start": "node server.js", "test": "vows test/*.js", "preinstall": "./configure", "install": "make && make install" }, "engines": { "node": "0.4.x" } }
这个例子里我们定义了应用的入口文件( main )为 index ，当其他应用引用了我们的模块 require('test') 时，这个 main 的值 index.js 文件被调用。脚本( scripts )使用hash 表定义了几个不同的命令。script.start 里的定义的 node server.js 会在 npm start 时被调用，同样的 npm test 调用时对应的 scripts.test 里定义的命令被调用。在有些 native 模块需要编译的话，我们可以定义预编译和编译的命令。
本例中还定义了应用依赖模块( dependencies )和开发环境依赖模块( devDependencies )。应用依赖模块会在安装时安装到当前模块的 node_modules 目录下。开发环境依赖模块主要时在开发环境中用到的依赖模块，用命令 npm 的命令 install 或 link 加上参数 —dev 安装到当前模块的 node_modules 目录下。
name: package的名字（由于他会成为url的一部分，所以 non-url-safe 的字母不会通过，也不允许出现"."、"_"），最好先在[](上搜下你取的名字是否已经存在)
version: package的版本，当package发生变化时，version也应该跟着一起变化，同时，你声明的版本需要通过semver的校验（semver可自行谷歌）
dependencies: package的应用依赖模块，即别人要使用这个package，至少需要安装哪些东东。应用依赖模块会安装到当前模块的node_modules目录下。
devDependencies：package的开发依赖模块，插件发布的时候自动删除不相关代码。用个文件记录一下当前项目中安装或者需要的插件，即别人要在这个package上进行开发，可以一键安装项目所需插件。
2.版本号
大家也注意到 package.json 里的版本号有些是 >= 0.6.7 有些是 1.x.x，这有什么区别？npm 使用于语义化的版本识别来进行版本管理。并不是所有的模块都会提供向后兼容性，有时候某些模块因为某些原因导致不向后兼容。所以我们需要定义一些规则来保证模块能够在某些特定的版本中可用，并且保证能用最新的版本，因为那些版本总是修改了一些 bug 或提升了性能等。我们来看一下版本定义的字段：
例子:0.4.2
+ 大版本(0)
+ 小版本(4)
+ 补丁版本(2)
一个软件发布的时候，默认就是 1.0.0 版。如果以后发布补丁，就增加最后一位数字，比如1.0.1；如果增加新功能，且不影响原有的功能，就增加中间的数字（即小版本号），比如1.1.0；如果引入的变化，破坏了向后兼容性，就增加第一位数字（即大版本号），比如2.0.0。
在上面 package.json 的定义里我们确信模块在所有的 Nodejs 0.4及以上和0.5以下版本里都能运行。依赖模块 redis 在所有大于或等于0.6.7的版本上都能运行，依赖模块 ejs 只能确保运行在0.4.2版本里，依赖模块 express 确保能够兼容大于或等于1.0.0并且小于2.0.0。
生成
npm init
用来初始化生成一个新的package.json文件。它会向用户提问一系列问题，如果你觉得不用修改默认配置，一路回车就可以了。
如果使用了-f（代表force）、-y（代表yes），则跳过提问阶段，直接生成一个新的package.json文件。
您可能感兴趣的文章: