本文最后更新于：6 个月前

package.json几乎在每个开发项目中都会用到，可是你真的了解它吗？

package.json文件解读

一、依赖配置

1. 版本号

版本匹配策略

^, ~, * 这些不同的版本号前缀分别代表什么含义？

3.0.0		# 代表唯一的版本号，不支持更新，npm install --save-exact
^1.0.1、1、1.x	# 代表了可以命中主版本一致、但更新的版本号。
~1.0.1、1.1、1.1.x	# 代表了可以命中主版本、次版本一致、但更新的版本号。
* 和 x		# 可以命中一切新发布的版本号。

2. 各种dependencies

2.1 dependencies

生产环境的依赖包，构建项目时，会被一起打包

2.2 devDependencies

开发依赖，仅在开发期间使用，构建时不会被打包

2.3 peerDependencies

对等依赖，作用如下：

减小打包体积：例如使用react开发的组件库，安装react是必不可少的，而使用组件库的开发者，本地项目肯定安装了react，因此开发的组件库中不必把react打包进去（期望项目的使用者来提供这些模块的实现）。
版本一致性：使用你的组件库的开发者需要确保他们项目中安装了与你声明的对等依赖版本兼容的包，以确保组件库正常运行。

示例：声明要使用组件库，需在项目中安装大于17.0.1版本的react

1
2
3

"peerDependencies": {
    "react": ">17.0.1"
 }

3. engines

声明对npm或node的版本要求

"engines": {
  "node": ">=8.10.3 <12.13.0",
  "npm": ">=6.9.0"
}

目前对NPM来说，engines只是起一个说明的作用，即使用户安装的版本不符合要求，也不影响依赖包的安装。但使用pnpm 和 yarn安装，如果版本不符合要求会导致安装失败。

4. workspaces

monorepo专属。单个代码库中统一管理多个包（monorepo），在workspaces声明目录下的package会软链到根目录的node_modules中。

二、脚本配置

1. scripts

scripts 是 package.json中内置的脚本入口，是key-value键值对配置，key为可运行的命令，可以通过 npm run 来执行命令。除了运行基本的scripts命令，还可以结合pre和post完成前置和后续操作。先来看一组scripts：

"scripts": {
	"dev": "node index.js",
  "predev": "node beforeIndex.js",
  "postdev": "node afterIndex.js"
}

这三个js文件中都有一句console：

// index.js
console.log("scripts: index.js")
// beforeIndex.js
console.log("scripts: before index.js")
// afterIndex.js
console.log("scripts: after index.js")

当我们执行npm run dev命令时，输出结果如下：

1
2
3

scripts: before index.js
scripts: index.js
scripts: after index.js

可以看到，三个命令都执行了，执行顺序是predev→dev→postdev。如果scripts命令存在一定的先后关系，则可以使用这三个配置项，分别配置执行命令。

2. config

config字段用来配置scripts运行时的配置参数，如下所示：

1
2
3

"config": {
	"port": 3000
}

三、其它配置

1. type

指定模块系统的使用方式，

“commonjs”
“module” —— ES Module模式
“umd”
“json”

1	`"type": "module"`

2. private

1 2	`"private": true //禁止发送到npm服务器 "private": false //允许`

3. main

main 字段用来指定加载的入口文件，在 browser 和 Node 环境中都可以使用。

1	`"main": "./src/index.js",`

如果 npm 包只在 web 端使用，并且严禁在 server 端使用，使用 browser 来定义入口文件。

如果 npm 包导出的是 ESM 规范的包，使用 module 来定义入口文件。

1	`"module": "./src/index.mjs",`

四、第三方配置

1. lint-staged

"lint-staged": {
	"*.js": [
  	"eslint --fix",
    "git add"
  ]
}

配置后每次修改一个文件即可给所有文件执行一次lint检查，通常配合gitHooks一起使用

2. gitHooks

1
2
3

"gitHooks": {
	"pre-commit": "lint-staged"
}

gitHooks用来定义一个钩子，在提交（commit）之前执行ESlint检查。

3. browerslist

browserslist字段用来告知支持哪些浏览器及版本。Babel、Autoprefixer 和其他工具会用到它，以将所需的 polyfill 和 fallback 添加到目标浏览器。

五、package-lock.json

有了package.json为什么还要有它？它起什么作用？

先看以下场景：

依赖 A 安装时下载了最新版，如 1.2.3，出现了兼容问题，项目出现 bug；
依赖 A 所依赖的 B 和 C 下载了别的版本，导致 A 出现问题，从而项目出现问题

它的作用就是：锁定安装时的包的版本号及包的依赖的版本号, 以保证其他所有人在使用 npm install 时下载的依赖包都是一致的

关于 package.json 和 package-lock.json 的几个小结论：

package.json 用于告诉 npm 项目运行需要哪些包, 但包的最终安装的版本不能够只依靠这个文件进行识别, 还需以 package-lock.json 为准
package.json 中修改版本号会影响 package-lock.json, 并且 package.json 比 package.lock.json 的优先级高
为了保证该项目的环境依赖一致, 在项目移动时需要同时复制 package.json 和 package-lock.json 两个文件
不要轻易动 package.json 与 package-lock.json

删除重装一时爽，版本不对火葬场！！！