vue-cli脚⼿架之package.json
package.json⽂件配置及其含义，这个是vue-cli⾃动⽣成的⽂件，先贴⼀张代码及其含义：
{
"name": "secondproject",//模块名称
"version": "1.0.0",//模块版本
"description": "A Vue.js project",//对模块的描述
"author": "datura",//作者是谁
"private": true,//如果值为true,npm将拒绝发布它
"scripts": {//值是⼀个对象，⾥⾯指定了项⽬的⽣命周期各个环节需要执⾏的命令
"dev": "node build/dev-server.js",//这个就是在命令⾏执⾏npm run dev，其实是运⾏dev-server.js⽂件
"build": "node build/build.js",//build命令（有⼀个钩⼦的概念：⽐如这个build有prebuild和postbuild
"unit": "cross-env BABEL_ENV=test karma start test/f.js --single-run",//babel是⼀个编译器，可以把ES6编译成ES5.，这句先是设置编译环境为test环境下；karma是⼀个运⾏时，它产⽣⼀个web服务环境来运⾏项⽬代码，并执⾏测 "e2e": "node test/e2e/runner.js",//e2e模拟⽤户⾏为的测试，端到端测试
"test": "npm run unit && npm run e2e"//执⾏单元测试和e2e测试
},//关于npm钩⼦：通常程序只能处理来⾃内部的消息，如果希望对外部发来的消息也能拦截处理，就需要⽤到Hook技术。⽐如想在run build之前⾃动执⾏点任务，可以将其写在run prebuild标签⾥；postbuild在build之后⾃动执⾏
"dependencies": {//配置模块依赖的模块列表，key是模块名称，value是版本范围，版本范围是⼀个字符，可被⼀个或多个空格分割。
"router": "^1.3.0",//路由版本
"vue": "^2.2.1",//vue版本
"vue-resource": "^1.2.1",//⼀个插件，通过xmlHttpRequest或jsonp发起请求并处理响应。
"vue-router": "^2.3.0"//
},
"devDependencies": {//这⾥写的依赖是⽤于开发环境的，不发布到⽣产环境。
"autoprefixer": "^6.7.2",
"babel-core": "^6.22.1",
"babel-loader": "^6.2.10",
"babel-plugin-transform-runtime": "^6.22.0",
"babel-preset-latest": "^6.22.0",
"babel-preset-stage-2": "^6.22.0",
"babel-register": "^6.22.0",
"chalk": "^1.1.3",
"connect-history-api-fallback": "^1.3.0",
"copy-webpack-plugin": "^4.0.1",
"css-loader": "^0.26.1",
"eventsource-polyfill": "^0.9.6",
"express": "^4.14.1",
"extract-text-webpack-plugin": "^2.0.0",
"file-loader": "^0.10.0",
"friendly-errors-webpack-plugin": "^1.1.3",
"function-bind": "^1.1.0",
"html-webpack-plugin": "^2.28.0",
"http-proxy-middleware": "^0.17.3",
"webpack-bundle-analyzer": "^2.2.1",
"cross-env": "^3.1.4",
"karma": "^1.4.1",
"karma-coverage": "^1.1.1",
"karma-mocha": "^1.3.0",
"karma-phantomjs-launcher": "^1.0.2",
"karma-sinon-chai": "^1.2.4",
"karma-sourcemap-loader": "^0.3.7",
"karma-spec-reporter": "0.0.26",
"karma-webpack": "^2.0.2",
"lolex": "^1.5.2",
"mocha": "^3.2.0",
"chai": "^3.5.0",
"sinon": "^1.17.7",
"sinon-chai": "^2.8.0",
"inject-loader": "^2.0.1",
"babel-plugin-istanbul": "^3.1.2",
"phantomjs-prebuilt": "^2.1.14",
"chromedriver": "^2.27.2",
"cross-spawn": "^5.0.1",
"nightwatch": "^0.9.12",
"selenium-server": "^3.0.1",
"semver": "^5.3.0",
"opn": "^4.0.2",
"optimize-css-assets-webpack-plugin": "^1.3.0",
"ora": "^1.1.0",
"rimraf": "^2.6.0",
"url-loader": "^0.5.7",
"vue-loader": "^11.0.0",
"vue-style-loader": "^2.0.0",
"vue-template-compiler": "^2.2.1",
"webpack": "^2.2.1",
"webpack-dev-middleware": "^1.10.0",
"webpack-hot-middleware": "^2.16.1",
"webpack-merge": "^2.6.1"
},
"engines": {//指定项⽬运⾏的node或者npm版本范围，有点像安卓的指定开发level哦
"node": ">= 4.0.0",
"npm": ">= 3.0.0"
},
"browserlist": [//在不同的前端⼯具之间共享⽬标浏览器的库，确定哪些⽀持哪些版本的浏览器
"> 1%",//全球有超1%的⼈使⽤的浏览器
"last 2 versions",//根据CanIUse追踪的最后两个版本的所有浏览器
"not ie <= 8"//排除先前查询选择的浏览器天啦噜英语不好是硬伤不知怎么翻译好理解
]
}
这块想插播⼀篇⽂章，关于package.json⽂件讲的很详细很好理解，可以作为参考⼿册收藏啦。
附上原⽂链接：
概述
本⽂档是⾃⼰看官⽅⽂档的理解+翻译，内容是package.json配置⾥边的属性含义。package.json必须是⼀个严格的json⽂件，⽽不仅仅是js⾥边的⼀个对象。其中很多属性可以
通过npm-config来⽣成。
name
package.json中最重要的属性是name和version两个属性，这两个属性是必须要有的，否则模块就⽆法被安装，这两个属性⼀起形成了⼀个npm模块的唯⼀标识符。模块中内容
变更的同时，模块版本也应该⼀起变化。
name属性就是你的模块名称，下⾯是⼀些命名规则:
name必须⼩于等于214个字节，包括前缀名称在内（如 xxx/xxxmodule）。
name不能以"_"或"."开头
不能含有⼤写字母
name会成为url的⼀部分，不能含有url⾮法字符
下⾯是官⽹⽂档的⼀些建议：
不要使⽤和node核⼼模块⼀样的名称
name中不要含有"js"和"node"。 It's assumed that it's js, since you're writing a package.json file, and you can specify the engine using the "engines" field. (See below.)
name属性会成为模块url、命令⾏中的⼀个参数或者⼀个⽂件夹名称，任何⾮url安全的字符在name中都不能使⽤，也不能以"_"或"."开头
name属性也许会被写在require()的参数中，所以最好取个简短⽽语义化的值。
创建⼀个模块前可以先到后边的⽹址查查name是否已经被占⽤.
name属性可以有⼀些前缀如 e.g. @myorg/mypackage.在npm-scope(7)的⽂档中可以看到详细说明
version
version必须可以被npm依赖的⼀个node-semver模块解析。具体规则见下⾯的dependencies模块
description
⼀个描述，⽅便别⼈了解你的模块作⽤，搜索的时候也有⽤。
keywords
⼀个字符串数组，⽅便别⼈搜索到本模块
homepage
项⽬主页url
注意: 这个项⽬主页url和url属性不同，如果你填写了url属性，npm注册⼯具会认为你把项⽬发布到其他地⽅了，获取模块的时候不会从npm官⽅仓库获取，⽽是会重定向到url属性配置的地址。
（原⽂档中⽤了 spit(吐)这个单词，作者表⽰他不是在开玩笑:）
bugs
填写⼀个bug提交地址或者⼀个邮箱，被你的模块坑到的⼈可以通过这⾥吐槽，例如：
{ "url" : "github/owner/project/issues"
, "email" : "project@hostname"
}
url和email可以任意填或不填，如果只填⼀个，可以直接写成⼀个字符串⽽不是对象。如果填写了url，npm bugs命令会使⽤这个url。
license
你应该为你的模块制定⼀个协议，让⽤户知道他们有何权限来使⽤你的模块，以及使⽤该模块有哪些限制。最简单的，例如你⽤BSD-3-Clause 或 MIT之类的协议，如下：{ "license" : "BSD-3-Clause" }
你可以在这个地址查阅协议列表。
js获取json的key和value和⽤户相关的属性: author, contributors
"author"是⼀个码农， "contributors"是⼀个码农数组。 "person"是⼀个有⼀些描述属性的对象，如下 like this:
{ "name" : "Barney Rubble"
, "email" : "b@rubble"
, "url" : "barnyrubble.tumblr/"
}
也可以按如下格式缩写，npm会帮着转换:
"Barney Rubble ()"
email和url属性实际上都是可以省略的。描述⽤户信息的还有⼀个"maintainers"（维护者）属性。
files
"files"属性的值是⼀个数组，内容是模块下⽂件名或者⽂件夹名，如果是⽂件夹名，则⽂件夹下所有的⽂件也会被包含进来（除⾮⽂件被另⼀些配置排除了）
你也可以在模块根⽬录下创建⼀个".npmignore"⽂件（windows下⽆法直接创建以"."开头的⽂件，使⽤linux命令⾏⼯具创建如git bash），写在这个⽂件⾥边的⽂件即便被写在files属性⾥边也会被排除在外，这个⽂件的写法".gitignore"类似。
main
main属性指定了程序的主⼊⼝⽂件。意思是，如果你的模块被命名为foo，⽤户安装了这个模块并通过require("foo")来使⽤这个模块，那么require返回的内容就是main属性指定的⽂件中 ports指向的对象。
它应该指向模块根⽬录下的⼀个⽂件。对⼤对数模块⽽⾔，这个属性更多的是让模块有⼀个主⼊⼝⽂件，然⽽很多模块并不写这个属性。
bin
很多模块有⼀个或多个需要配置到PATH路径下的可执⾏模块，npm让这个⼯作变得⼗分简单（实际上npm本⾝也是通过bin属性安装为⼀个可执⾏命令的）
如果要⽤npm的这个功能，在package.json⾥边配置⼀个bin属性。bin属性是⼀个已命令名称为key，本地⽂件名称为value的map如下：
{ "bin" : { "myapp" : "./cli.js" } }
模块安装的时候，若是全局安装，则npm会为bin中配置的⽂件在bin⽬录下创建⼀个软连接（对于windows系统，默认会在C:\Users\username\AppData\Roaming\npm⽬录下），若是局部安装，则会在项⽬内的./node_modules/.bin/⽬录下创建⼀个软链接。
因此，按上⾯的例⼦，当你安装myapp的时候，npm就会为cli.js在/usr/local/bin/myapp路径创建⼀个软链接。
如果你的模块只有⼀个可执⾏⽂件，并且它的命令名称和模块名称⼀样，你可以只写⼀个字符串来代替上⾯那种配置，例如：
{ "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
制定⼀个或通过数组制定⼀些⽂件来让linux下的man命令查⽂档地址。
如果只有⼀个⽂件被指定的话，安装后直接使⽤man+模块名称，⽽不管man指定的⽂件的实际名称。例如:
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : "./man/doc.1"
}
通过man foo命令会得到 ./man/doc.1 ⽂件的内容。
如果man⽂件名称不是以模块名称开头的，安装的时候会给加上模块名称前缀。因此，下⾯这段配置：
{ "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的哪个部分。
{ "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通过directories来制定⼀些⽅法来描述模块的结构，看看npm的package.json⽂件，可以发现⾥边有这个字段的内容。
⽬前这个配置没有任何作⽤，将来可能会整出⼀些花样来。
directories.lib
告诉⽤户模块中lib⽬录在哪，这个配置⽬前没有任何作⽤，但是对使⽤模块的⼈来说是⼀个很有⽤的信息。
directories.bin
如果你在这⾥指定了bin⽬录，这个配置下⾯的⽂件会被加⼊到bin路径下，如果你已经在package.json中配置了bin⽬录，那么这⾥的配置将不起任何作⽤。directories.man
指定⼀个⽬录，⽬录⾥边都是man⽂件，这是⼀种配置man⽂件的语法糖。
directories.doc
在这个⽬录⾥边放⼀些markdown⽂件，可能最终有⼀天它们会被友好的展现出来（应该是在npm的⽹站上）
放⼀些⽰例脚本，或许某⼀天会有⽤ - -！
repository
指定⼀个代码存放地址，对想要为你的项⽬贡献代码的⼈有帮助。像这样：
"repository" :
{ "type" : "git"
, "url" : "github/npm/npm.git"
}
"repository" :
{ "type" : "svn"
, "url" : "v8.googlecode/svn/trunk/"
}
若你的模块放在GitHub, GitHub gist, Bitbucket, or GitLab的仓库⾥，npm install的时候可以使⽤缩写标记来完成：
"repository": "npm/npm"
"repository": "gist:11081aaa281"
"repository": "bitbucket:example/repo"
"repository": "gitlab:another/repo"
scripts
scripts属性是⼀个对象，⾥边指定了项⽬的⽣命周期个各个环节需要执⾏的命令。key是⽣命周期中的事件，value是要执⾏的命令。
具体的内容有 install start stop 等，详见
config
⽤来设置⼀些项⽬不怎么变化的项⽬配置，例如port等。
⽤户⽤的时候可以使⽤如下⽤法：
可以通过npm config set foo:port 80来修改config。详见
, "config" : { "port" : "8080" } }
dependencies
dependencies属性是⼀个对象，配置模块依赖的模块列表，key是模块名称，value是版本范围，版本范围是⼀个字符，可以被⼀个或多个空格分割。dependencies也可以被指定为⼀个git地址或者⼀个压缩包地址。
不要把测试⼯具或transpilers写到dependencies中。下⾯是⼀些写法，详见
version 精确匹配版本
>version 必须⼤于某个版本
>=version ⼤于等于
<version ⼩于
<=versionversion ⼩于
~version "约等于"，具体规则详见semver⽂档
^version "兼容版本"具体规则详见semver⽂档
1.2.x 仅⼀点⼆点⼏的版本
... 见下⾯url作为denpendencies的说明
任何版本
"" 空字符，和*相同
version1 - version2 相当于 >=version1 <=version2.
range1 || range2 范围1和范围2满⾜任意⼀个都⾏
< 见下⾯git url作为denpendencies的说明
user/repo See 见下⾯GitHub仓库的说明
tag 发布的⼀个特殊的标签，见npm-tag的⽂档
path/path/path 见下⾯本地模块的说明
下⾯的写法都是可以的:
{ "dependencies" :
{ "foo" : "1.0.0 - 2.9999.9999"
, "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/"
,
"til" : "~1.2"
, "elf" : "~1.2.3"
, "two" : "2.x"
, "thr" : "3.3.x"
, "lat" : "latest"
, "dyl" : "file:../dyl"
}
}
URLs as Dependencies
在版本范围的地⽅可以写⼀个url指向⼀个压缩包，模块安装的时候会把这个压缩包下载下来安装到模块本地。
Git URLs as Dependencies
Git url可以像下⾯⼀样:
git://github/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+ssh://user@hostname/project.git#commit-ish
git+user@hostname/project/blah.git#commit-ish
git+user@hostname/project/blah.git#commit-ish
commit-ish 可以是任意标签，哈希值，或者可以检出的分⽀，默认是master分⽀。
GitHub URLs
⽀持github的 username/modulename 的写法，#后边可以加后缀写明分⽀hash或标签：
{
"name": "foo",
"version": "0.0.0",
"dependencies": {
"express": "visionmedia/express",
"mocha": "visionmedia/mocha#4727d357ea"
}
}
Local Paths
npm2.0.0版本以上可以提供⼀个本地路径来安装⼀个本地的模块，通过npm install xxx --save 来安装，格式如下：
../foo/bar
~/foo/bar
./foo/bar
/foo/bar
package.json ⽣成的相对路径如下:
{
"name": "baz",
"dependencies": {
"bar": "file:../foo/bar"
}
}
这种属性在离线开发或者测试需要⽤npm install的情况，⼜不想⾃⼰搞⼀个npm server的时候有⽤，但是发布模块到公共仓库时不应该使⽤这种属性。devDependencies
如果有⼈想要下载并使⽤你的模块，也许他们并不希望或需要下载⼀些你在开发过程中使⽤的额外的测试或者⽂档框架。
在这种情况下，最好的⽅法是把这些依赖添加到devDependencies属性的对象中。
这些模块会在npm link或者npm install的时候被安装，也可以像其他npm配置⼀样被管理，详见npm的config⽂档。
对于⼀些跨平台的构建任务，例如把CoffeeScript编译成JavaScript，就可以通过在package.json的script属性⾥边配置prepublish脚本来完成这个任务，然后需要依赖的coffee-script模块就写在devDependencies属性种。
例如:
{ "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 ffee"
},
"main": "lib/waza.js"
}
prepublish脚本会在发布之前运⾏，因此⽤户在使⽤之前就不⽤再⾃⼰去完成编译的过程了。在开发模式下，运⾏npm install也会执⾏这个脚本（见npm script⽂档），因此可以很⽅便的调试。
peerDependencies
有时候做⼀些插件开发，⽐如grunt等⼯具的插件，它们往往是在grunt的某个版本的基础上开发的，⽽在他们的代码中并不会出现require("grunt")这样的依赖，dependencies配置⾥边也不会写上grunt的依赖，为了说明此模块只能作为插件跑在宿主的某个版本范围下，可以配置peerDependencies：
{
"name": "tea-latte",
"version": "1.3.5",
"peerDependencies": {
"tea": "2.x"
}
}
上⾯这个配置确保再npm install的时候tea-latte会和2.x版本的tea⼀起安装，⽽且它们两个的依赖关系是同级的：
├──
└──
这个配置的⽬的是让npm知道，如果要使⽤此插件模块，请确保安装了兼容版本的宿主模块。
bundledDependencies
上⾯的单词少个d，写成bundleDependencies也可以。
指定发布的时候会被⼀起打包的模块。
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()
}
optionalDependencies 中的配置会覆盖dependencies中的配置，最好只在⼀个地⽅写。
engines
你可以指定项⽬运⾏的node版本范围，如下：
{ "engines" : { "node" : ">=0.10.3 <0.12" } }
和dependencies⼀样，如果你不指定版本范围或者指定为*，任何版本的node都可以。
也可以指定⼀些npm版本可以正确的安装你的模块，例如：
{ "engines" : { "npm" : "~1.0.20" } }
要注意的是，除⾮你设置了engine-strict属性，engines属性是仅供参考的。
engineStrict
注意：这个属性已经弃⽤，将在npm 3.0.0 版本⼲掉。
os
可以指定你的模块只能在哪个操作系统上跑：
"os" : [ "darwin", "linux" ]
也可以指定⿊名单⽽不是⽩名单：
"os" : [ "!win32" ]
服务的操作系统是由process.platform来判断的，这个属性允许⿊⽩名单同时存在，虽然没啥必要这样搞...
cpu
限制模块只能在某某cpu架构下运⾏
"cpu" : [ "x64", "ia32" ]
同样可以设置⿊名单:
"cpu" : [ "!arm", "!mips" ]
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论