package.json---入门说明

直接的说：就是管理你本地安装的npm包 
一个package.json文件能够作以下事情：

展现项目所依赖的npm包 
容许你指定一个包的版本[范围] 
让你创建起稳定，意味着你能够更好的与其余开发者共享

建立package.json

在你要建立的目录下执行：npm init，系统会一一提示设置相关配置。提示设置的字段均为必填字段（有的能够用回车键，即设置为空带过）

• npm init –yes|-y: 执行此命令，则会直接建立一个package.json，只配置了一些必填字段，而且给出默认值。其中name: 所处的文件夹名称

package.json配置说明

这里说的项目广义，好比：咱们能够把咱们的项目发布成一个npm包

• name: 项目名称
• version: 项目版本号
• description: 项目描述
• keywords: {Array}关键词，便于用户搜索到咱们的项目
• homepage: 项目url主页

• bugs: 项目问题反馈的Url或email配置，如： 
  {  
  “url” : “https://github.com/owner/project/issues“, 
  “email” : “project@hostname.com” 
  }

• license: 项目许可证，让使用者知道是如何被容许使用此项目。默认是”ISC”

• author,contributors: 做者和贡献者。格式设置以下： 
  { “name” : “Barney Rubble” 
  , “email” : “b@rubble.com” 
  , “url” : “http://barnyrubble.tumblr.com/” 
  }

• files: 包含在项目中的文件数组。若是在数组里面声明了一个文件夹，那也会包含文件夹中的文件。能够声明一些规则来忽略部分文件。能够在项目根目录或者子目录里声明一个.npmignore。

Certain files are always included, regardless of settings:

package.json 
README (and its variants) 
CHANGELOG (and its variants) 
LICENSE / LICENCE 
Conversely, some files are always ignored:

.git 
CVS 
.svn 
.hg 
.lock-wscript 
.wafpickle-N 
*.swp 
.DS_Store 
._* 
npm-debug.log

• main: 主文件。好比默认是index.js，项目名称叫mymodule。那么require(‘mymodule’)将返回index.js返回的内容
• bin: 项目用到的可执行文件配置
• man: 指定一个单一的文件名或一个文件名数组。意思相似于linux命令中的man 命令，来查看一个命令的用法 
  

  若是只给man字段提供一个文件，则安装完毕后，它就是man 的结果，这和此文件名无关 

  { 
  “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后缀(当它被压缩时)。这个数字说明了这个文件被安装到哪一个节中

{ 
“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 Packages规范说明了几种你能够用directories对象来标示你的包结构的方法
• directories.lib: 告诉你库文件夹的位置，目前没有什么地方须要用到lib文件夹，可是这是重要的元信息

• directories.bin: 若是你在directories.bin中指定一个bin目录，在这个目录中的全部文件都会被当作在bin来使用。

  因为bin指令的工做方式，同时指定一个bin路径和设置directories.bin将是一个错误。若是你想指定独立的文件，使用bin，若是想执行某个文件夹里的全部文件，使用directories.bin。

• directories.doc: 把markdown文件放在这。也许某一天这些文件将被漂亮地展现出来，不过这仅仅是也许

• directories.man: directories.man指定的文件夹里都是man文件，系统经过遍历这个文件夹来生成一个man的数组
• directories.example: 把示例脚本放在这。也许某一天会被用到

• repository: 项目代码存放地方

  “repository” : 
  { “type” : “git” 
  , “url” : “https://github.com/npm/npm.git” 
  } 
  “repository” : 
  { “type” : “svn” 
  , “url” : “https://v8.googlecode.com/svn/trunk/” 
  }

• scripts: 声明一系列npm脚本指令

  1. prepublish: 在包发布以前运行，也会在npm install安装到本地时运行
  2. publish,postpublish: 包被发布以后运行
  3. preinstall: 包被安装前运行
  4. install,postinstall: 包被安装后运行
  5. preuninstall,uninstall: 包被卸载前运行
  6. postuninstall: 包被卸载后运行
  7. preversion: bump包版本前运行
  8. postversion: bump包版本后运行
  9. pretest,test,posttest: 经过npm test命令运行
  10. prestop,stop,poststop: 经过npm stop命令运行
  11. prestart,start,poststart: 经过npm start命令运行
  12. prerestart,restart,postrestart: 经过npm restart运行

  13. "scripts": {

              "dev": "npm run start",

              "dist": "cross-env NODE_ENV=production node ./tools/script.js",

              "lint": "eslint src/ --ext .js,.vue && stylelint \"src/**/*.vue\" --syntax less",

              "lint:js": "eslint src/ --ext .js,.vue",

              "lint:style": "stylelint src/**/*.less --syntax less",

              "pub": "npm run dist",

              "start": "cross-env NODE_ENV=development node ./tools/script.js",

              "test": ""

          }

• config: 配置项目中须要的配置参数：

  { “name” : “foo” 
  , “config” : { “port” : “8080” } 
  , “scripts” : { “start” : “node server.js” } } } 
  server.js中使用process.env.npm_package_config_port来访问port 
  用户也能够这样修改：npm config set foo:port 80

• dependencies: 项目在生产环境中依赖的包

• devDependencies: 项目在开发和测试环境中依赖的包

• peerDependencies: 在某些状况下，当一个主机没法require依赖包时，你会想要告诉它还有哪些工具或库与这个依赖包兼容。这一般被成为一个插件。尤为是在host文档中声明的模块会暴露一个特定的接口

  { 
  “name”: “tea-latte”, 
  “version”: “1.3.5”, 
  “peerDependencies”: { 
  “tea”: “2.x” 
  } 
  } 
  这将确保tea-latte这个包只会和2.x版本的tea一块儿被安装。执行npm install tea-latte可能产生如下关系图： 
  ├── tea-latte@1.3.5 
  └── tea@2.2.0

• bundledDependencies: {Array}，发布时会被一块儿打包的模块

• optionalDependencies: 若是一个依赖模块能够被使用， 同时你也但愿在该模块找不到或没法获取时npm继续运行，你能够把这个模块依赖放到optionalDependencies配置中。这个配置的写法和dependencies的写法同样，不一样的是这里边写的模块安装失败不会致使npm install失败。固然，这种模块就须要你本身在代码中处理模块确实的状况了，例如：

  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() 
  }

• engines: 声明项目须要的node或npm版本范围

  { “engines” : { “npm” : “~1.0.20” } } 
  { “engines” : { “node” : “>=0.10.3 <0.12” } }

• os: 指定你的项目将运行在什么操做系统上

• cpu: 指定你的项目将运行在什么cpu架构上
• preferGlobal: 若是你的包须要全局安装，经过命令行来运行，那么设置为true。若是这个包被本地安装则会出现一个警告
• private: 若是设置为true, 那么npm会拒绝发布它
• publishConfig