一、概述
每个项目的根目录下面，一般都有一个package.json文件，定义了这个项目所需要的各种模块，以及项目的配置信息（比如名称、版本、许可证等元数据）。
npm install命令根据这个配置文件，自动下载所需的模块，也就是配置项目所需的运行和开发环境。
下面是一个最简单的package.json文件，只定义两项元数据：项目名称和项目版本。
{
"name": "platform-front",
"version": "4.4.0",
"description": "A magical vue admin. An out-of-box UI solution for enterprise applications. Newest development stack of vue. Lots of awesome features",
"author": "payn <qiaoxiazhimin@163.com>"
}
package.json文件就是一个JSON对象，该对象的每一个成员就是当前项目的一项设置。比如name就是项目名称，version是版本（遵守“大版本.次要版本.小版本”的格式）。
二、配置详解
2.1、scripts
scripts指定了运行脚本命令的npm命令行缩写，比如start指定了运行npm run start时，所要执行的命令。
"scripts": {
"dev": "vue-cli-service serve",
"lint": "eslint --ext .js,.vue src",
"build:prod": "vue-cli-service build",
"build:stage": "vue-cli-service build --mode staging",
"preview": "node build/index.js --preview",
"new": "plop",
"svgo": "svgo -f src/icons/svg --config=src/icons/svgo.yml",
"test:unit": "jest --clearCache && vue-cli-service test:unit",
"test:ci": "npm run lint && npm run test:unit"
}
其中
- dev：构建开发环境
- lint：基于eslint插件检测代码
- build:prod：构建生产环境
- build:stage：构建测试环境
- preview：预览发布环境效果
- new：基于plop插件生成模板文件
- svgo：基于svg插件压缩优化svg文件
- test:unit：构建单元测试
- test:ci：构建自动化测试
2.2、dependencies & devDependencies
dependencies字段指定了项目运行所依赖的模块。
devDependencies指定项目开发所需要的模块。
它们都指向一个对象。该对象的各个成员，分别由模块名和对应的版本要求组成，表示依赖的模块及其版本范围。
对应的版本可以加上各种限定，主要有以下几种：
- 指定版本：比如1.2.2，遵循“大版本.次要版本.小版本”的格式规定，安装时只安装指定版本。
- 波浪号（tilde）+指定版本：比如~1.2.2，表示安装1.2.x的最新版本（不低于1.2.2），但是不安装1.3.x，也就是说安装时不改变大版本号和次要版本号。
- 插入号（caret）+指定版本：比如ˆ1.2.2，表示安装1.x.x的最新版本（不低于1.2.2），但是不安装2.x.x，也就是说安装时不改变大版本号。需要注意的是，如果大版本号为0，则插入号的行为与波浪号相同，这是因为此时处于开发阶段，即使是次要版本号变动，也可能带来程序的不兼容。
- latest：安装最新版本。
package.json文件可以手工编写，也可以使用npm init命令自动生成。
npm init
这个命令采用互动方式，要求用户回答一些问题，然后在当前目录生成一个基本的package.json文件。所有问题之中，只有项目名称（name）和项目版本（version）是必填的，其他都是选填的。
有了package.json文件，直接使用npm install命令，就会在当前目录中安装所需要的模块。
npm install
如果一个模块不在package.json文件之中，可以单独安装这个模块，并使用相应的参数，将其写入package.json文件之中。
npm install express --save
npm install express --save-dev
上面代码表示单独安装express模块，—save参数表示将该模块写入dependencies属性，—save-dev表示将该模块写入devDependencies属性。
2.3、browserslist
browserlist是一个前端项目配置工具，功能是在前端工具之间共享目标环境的浏览器支持信息。
比如我们项目构建的时候一般会用到AutoPrifixer、Babel、PostCss、Eslint等插件，提供了对应的浏览器信息后，他们就会针对浏览器信息采取不同的编译策略。
"browserslist": [
"> 1%",
"last 2 versions"
]
browserslist 设置语法如下：
语法 说明
> 1% 全球超过1%人使用的浏览器
> 5% in US 指定国家使用率覆盖
last 2 versions 所有浏览器兼容到最后两个版本根据CanIUse.com追踪的版本
not ie <= 8 表示IE浏览器版本大于8（实则用npx browserslist 跑出来不包含IE9 ）
safari >= 7 表示safari浏览器版本大于等于7
2.4、bugs
这个字段其实是提供给使用者上报 bugs的途径, 可以填一个email或者一个issue地址。
"bugs": {
"url": "https://github.com/hidlestone/platform-front/issues"
}
2.5、engines
engines属性是键/值对的json对象，用于表示指定应用程序应在其上运行的库和运行的版本，这里设置 node 和 npm 两个应用程序。
"engines": {
"node": ">=8.9",
"npm": ">= 3.0.0"
}
2.6、keywords
keywords属性值是一组关键字数组，可以帮助你识别项目并且使其他用户在 npm 搜索关键字的时候容易找到你的项目。
"keywords": [
"vue",
"admin",
"dashboard",
"element-ui",
"boilerplate",
"admin-template",
"management-system"
]
当然，你得先提交到 npm 上，别人才能搜索到。
2.7、license
license属性表示项目正在使用的许可证类型。
"license": "MIT"
2.8、lint-staged
在代码提交之前，进行代码规则检查能够确保进入git库的代码都是符合代码规则的。但是整个项目上运行lint速度会很慢，lint-staged能够让lint只检测暂存区的文件，所以速度很快。
"lint-staged": {
"src/**/*.{js,vue}": [
"eslint --fix",
"git add"
]
},
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
}
git commit时触发 pre-commit 钩子，运行 lint-staged 命令，对 .js、.vue 文件执行 eslint 命令。eslint 要提前配置好。
2.9、repository
repository属性是键/值对的JSON对象，用于指定用于管理应用程序的版本控制系统。您可以指定使用的版本控制的类型，存储库的URL以及存储库内的可选目录。
"repository": {
"type": "git",
"url": "git+https://github.com/hidlestone/platform-front.git"
}
三、Package-lock.json
3.1、问题
在项目开发过程中遇到一个问题，同一个项目第一次 npm install 的时候还可以启动，过一段时间，把 node_modules 删掉，重新 npm install，发现项目启动报错了。
项目代码和之前一样，一点都没改动，为啥会报错呢？查其原因，发现是 package.json 文件的包版本号没有固定。
"roadhog": "^2.5.0-beta.4"
这里有个 ^ ,安装的时候会安装 2.x.x 的最新版本，因为这期间该模块有更新，导致两次 install 的版本不一样，所以项目报错了。
3.2、解决方法
既然插件包是动态更新的，为了避免包版本更新，我们把该包版本写死。
"roadhog": "2.5.0-beta.4"
npm 最方便的地方，是它可以帮我们管理包，自动下载包。假如我们依赖 roadhog ，roadhog 又依赖A、B 等，我们安装 roadhog 时，npm 会自动帮我们安装好 roadhog 依赖的包 A、B。
如果我们把 roadhog 锁死了，其引用的 A 包仍用的是 ^ 括号写法（即没有锁死版本），一旦 A 包更新了，仍可能会出现之前类似的问题，那么该怎么进行版本控制呢？
所以我们要对整个依赖树做锁定，那前后编译出来的应用版本就不会存在两次安装版本不一的问题了。
这就引出了我们的 package-lock.json 文件。它的产生就是来对整个依赖树进行版本固定的（锁死）
四、package-lock.json 配置详解
package-lock.json 它会在 npm 更改node_modules 目录树或者 package.json 时自动生成。
package-lock.json 准确的描述了当前项目 npm 包的依赖树，并且给每个包标明了版本, 获取地址和哈希值。
在随后的安装中会根据 package-lock.json里的内容来处理和安装包，而不再根据 package.json 来安装，确保每次安装都会出现相同的结果，不管你在什么机器或什么时候安装。
4.1、name
package-lock 包的文件名称
4.2、version
package-lock 包的版本号。
4.3、lockfileVersion
package-lock包的整数版本。
4.4、packages
这是一个包信息的简单定义，可以映射到具体的包信息，具有以下字段：
- version：包的版本号
- resolved: 包文件的实际地址
- integrity：包文件的签名，通常为 sha512 或 sha1 签名字符串
- link:是否是符号链接
- dev, optional, devOptional：如果包严格属于 devdependences 树，那么 dev 为 true;如果严格的属于 optionalDependencies 树的一部分，那么 optional 为 true；如果既是开发依赖项又是非开发依赖项的可选依赖项，那么 devOptional 为 true
- inBundle：是否是捆绑依赖
- …
4.5、dependencies
包所用到的依赖声明，依赖对象有以下属性：
- version：依赖包的版本好
- resolved: 依赖包文件的实际地址
- integrity：依赖包文件的签名，通常为 sha512 或 sha1 签名字符串
- bundled: 是否是捆绑依赖
- dev：是否严格依赖于 devdependences
- optional：是否依赖于 devdependences、optionalDependencies
- requires：该依赖需要的子依赖版本定义，这是一个子依赖版本的集合
- dependencies：没看明白，姑且认为是 requires 中子依赖的具体指定
参考：
https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json/
评论