在前端开发中，包的说明文件（package.json）起着至关重要的作用。它就像是一个包的“身份证”，提供了关于包的各种关键信息，帮助开发者更好地管理和使用包。现在，让我们深入了解 package.json 的各个配置项。

包的说明信息相关配置#

name：包的名字，必须是唯一的。这是识别一个包的重要标识，确保在整个 npm 生态系统中不会与其他包重名。

version：包的版本号，一般由三个数字组成，格式为 x.y.z。

• x 代表主版本号（Major Version），当软件包发生重大变化或者不兼容的升级时，需要增加主版本号。
• y 代表次版本号（Minor Version），当软件包增加新的功能或新的特性时，需要增加次版本号。
• z 代表修订号（Patch Version），当软件包进行 bug 修复、性能优化或较小的改动时，需要增加修订号。

description：包的描述信息，简短地描述包的功能和用途，帮助其他开发者快速了解这个包。

keyword：包的关键词，用于搜索和分类。例如：

author：作者信息，包括作者的名字、邮箱和个人网站等。例如：

contributors：包的贡献者名单，列出对这个包有贡献的人员信息。

license：包的许可证信息，指定包的开源类型，明确包的使用权限和限制。

repository：包的源代码仓库信息，可以提供一个 git 地址，方便其他开发者查看和贡献代码。例如：

engines：用来指定项目需要的 node 版本以及 npm 版本，避免用户在使用包的时候出现因为版本不支持而产生的问题。例如：

包执行相关配置#

main：代表包的入口文件，是包在被引入时的默认入口点。

browser：该选项表示如果是在浏览器环境下，可以替换一些特定模块或者文件。 指定浏览器的入口文件：

上面的配置表明在 node 环境下，index.js 为入口文件，如果是浏览器环境，使用 browser.js 作为入口文件。

替换特定的模块：

排除某些模块：

scripts：配置可执行命令，可以定义一些常用的命令，方便在开发过程中快速执行特定的任务。例如：

脚本还可以配置生命周期钩子方法，使用到的关键词为 pre 和 post，pre 代表在执行某个脚本之前，post 代表在执行某个脚本之后。例如：

• prestart：代表在执行 start 之前，先运行 build。

• posttest：代表在执行了 test 之后，同时运行 lint 以及 format。

包的依赖信息相关配置#

dependencies：包的依赖列表，最终打包的时候，会将这一部分依赖打包进去。例如，如果项目用到了 lodash，最终对项目进行打包的时候，就应该把 lodash 打包进去，所以 lodash 就应该记入到 dependencies。

devDependencies：这个代表开发依赖，开发的时候会用到，但是最终打包的时候不需要打包进去。例如 webpack、eslint、typescript、sass 等，这一部分依赖就应该记入到 devDependencies。

控制依赖版本的范围：有一些符号（^ ~）是专门用来控制依赖的版本范围的，这些符号用来指定依赖在更新的时候能够更新的范围。

• ^ （脱字符）：表示允许更新到相同主版本号的最新版本，也就是说次版本可以变，补丁版本可以变，但是主版本不能变。举个例子：^1.2.3 更新的时候，允许的范围就是 >= 1.2.3 且 < 2.0.0。

• ～（波浪字符）：表示主版本号和次版本号都必须相同，也就是说能够更新的只有补丁号。举个例子：～1.2.3 更新的时候，允许的范围为 >= 1.2.3 且 < 1.3.0。 关于版本范围的符号，其实远远不止上面两个，这有一套详细规则，可以参阅。

peerDependencies：该配置项通常用于开发插件或者库的时候，表示需要与项目（这里的项目指的是使用我们插件或者库的项目）一起使用的依赖，确保这些依赖有一个合适的版本。

• 假设在开发一个 react 插件，在开发 react 的时候肯定会涉及到使用 react 的环境，如果此时将 react 记入到 dependencies，那么则意味着别人项目在使用这个插件的时候，也会去下载 react。这里就会存在两个问题：一是别人既然使用这个插件，那么说明别人也是在做 react 的开发，别人的项目自然而然已经安装了 react；二是如果不记入到 dependencies 里面，那么又会存在因为版本不一致可能出现的兼容问题。

• peerDependencies 就是用来解决这个问题，例如现在在开发一个 react 的插件，用到了 react 以及 react-dom。

  { "name": "my-react-plugin", "version": "1.0.0", "peerDependencies": { "react": "^17.0.0", "react-dom": "^17.0.0" } }

回头别人在使用这个插件的时候，就必须确保安装符合版本要求的依赖。否则 npm 会给出警告。

讲到这里，有的同学会有这样的疑问，在开发插件的时候，直接将所有用到的依赖全部声明为 peerDependencies 是否合适？如果这么做，则意味着用户在使用这个插件的时候，需要手动去安装众多的依赖，假设插件有几十个依赖，那么用户就需要手动安装几十个依赖，这显然也是不合适的。

因此 peerDependencies 只会记入一个插件的主要依赖（angular、react、vue）。

下面有一些建议，可以帮助做出决策：

• 考虑插件的目标受众。如果认为大部分使用插件的项目都已经在使用所依赖的库（例如 lodash），那么将这些库声明为 peerDependencies 可能是合适的。

• 考虑插件与依赖项之间的紧密程度。如果插件仅依赖于依赖项的一个小功能，而且这个功能在未来版本中不太可能发生变化，那么可以将这个依赖项声明为 dependencies。

• 如果决定将某些库声明为 peerDependencies，请确保在插件的文档中明确提醒用户需要安装这些库。