npm包package.json字段解析
Author：zhoulujun Date：
package.json字段说明
yarn init -y 或 npm init -y 命令后，在项目目录下会新增一个 package.json文件，内容如下：
{
"name": "my-test", # 项目名称
"version": "1.0.0", # 项目版本（格式：大版本.次要版本.小版本）
"description": "", # 项目描述
"main": "index.js", # 入口文件
"scripts": { # 指定运行脚本命令的 npm 命令行缩写
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [], # 关键词
"author": "", # 作者
"license": "ISC" # 许可证
}可以看到，package.json 文件的内容是一个 JSON 对象，对象的每一个成员就是当前项目的一项配置。
必备属性（name & version）
package.json 中有非常多的配置项，其中必须填写的两个字段分别是 name 字段和 version 字段，它们是组成一个 npm 模块的唯一标识。
name 字段
name 字段定义了模块的名称，其命名时需要遵循官方的一些规范和建议：
模块名会成为模块 url、命令行中的一个参数或者一个文件夹名称，任何非 url 安全的字符在模块名中都不能使用（我们可以使用 validate-npm-package-name 包来检测模块名是否合法）；
语义化模块名，可以帮助开发者更快的找到需要的模块，并且避免意外获取错误的模块；
若模块名称中存在一些符号，将符号去除后不得与现有的模块名重复，例如：由于 react-router-dom 已经存在，react.router.dom、reactrouterdom 都不可以再创建。
name 字段不能与其他模块名重复，我们可以执行以下命令查看模块名是否已经被使用：
npm view <packageName>
如果该模块名从未被使用过，则会抛出 404 错误：
version 字段
npm 包中的模块版本都需要遵循 SemVer 规范，该规范的标准版本号采用 X.Y.Z 的格式，其中 X、Y 和 Z 均为非负的整数，且禁止在数字前方补零：
X 是主版本号(major)：修改了不兼容的 API
Y 是次版本号(minor)：新增了向下兼容的功能
Z 为修订号(patch)：修正了向下兼容的问题
当某个版本改动比较大、并非稳定而且可能无法满足预期的兼容性需求时，我们可能要先发布一个先行版本。
先行版本号可以加到主版本号.次版本号.修订号的后面，通过 - 号连接一连串以句点分隔的标识符和版本编译信息：
内部版本(alpha)
公测版本(beta)
正式版本的候选版本rc（即 Release candiate）
我们可以执行以下命令查看模块的版本：
npm view <packageName> version # 查看某个模块的最新版本
npm view <packageName> versions # 查看某个模块的所有历史版本
安装项目依赖（dependencies & devDependencies）
dependencies字段指定了项目运行所依赖的模块（生产环境使用），如 antd、 react、 moment等插件库：
它们是我们生产环境所需要的依赖项，在把项目作为一个 npm 包的时候，用户安装 npm 包时只会安装 dependencies 里面的依赖。
devDependencies 字段指定了项目开发所需要的模块（开发环境使用），如 webpack、typescript、babel等：
在代码打包提交线上时，我们并不需要这些工具，所以我们将它放入 devDependencies 中。
npm install <package...> --save # 写入 dependencies 属性
npm install <package...> --save-dev # 写入 devDependencies 属性
如果一个模块不在 package.json 文件之中，我们可以单独安装这个模块，并使用相应的参数，将其写入 dependencies 字段/ devDependencies 字段中：
定义项目入口（main）
main 字段是 package.json 中的另一种元数据功能，它可以用来指定加载的入口文件。假如你的项目是一个 npm 包，当用户安装你的包后，require('my-module') 返回的是 main 字段中所列出文件的 module.exports 属性。当不指定main 字段时，默认值是模块根目录下面的index.js 文件。
发布文件配置（files）
files 字段用于描述我们使用 npm publish 命令后推送到 npm 服务器的文件列表，如果指定文件夹，则文件夹内的所有内容都会包含进来。我们可以查看下载的 antd 的 package.json 的files 字段，内容如下：
"files": [ "dist", "lib", "es" ],
可以通过配置一个 .npmignore 文件来排除一些文件， 防止大量的垃圾文件推送到 npm 上。
指定模块适用系统（os）
假如我们开发了一个模块，只能跑在 darwin 系统下，我们需要保证 windows 用户不会安装到该模块，从而避免发生不必要的错误。这时候，使用 os 属性则可以帮助我们实现以上的需求，该属性可以指定模块适用系统的系统，或者指定不能安装的系统黑名单（当在系统黑名单中的系统中安装模块则会报错）：
"os" : [ "darwin", "linux" ] # 适用系统
"os" : [ "!win32" ] # 黑名单
Tips：在 node 环境下可以使用 process.platform 来判断操作系统。
指定模块适用 cpu 架构（cpu）
和上面的 os 字段类似，我们可以用 cpu 字段更精准的限制用户安装环境：
"cpu" : [ "x64", "ia32" ] # 适用 cpu
"cpu" : [ "!arm", "!mips" ] # 黑名单
Tips：在 node 环境下可以使用 process.arch 来判断 cpu 架构。
指定项目 node 版本（engines）
有时候，新拉一个项目的时候，由于和其他开发使用的 node 版本不同，导致会出现很多奇奇怪怪的问题（如某些依赖安装报错、依赖安装完项目跑不起来等）。
为了实现项目开箱即用的伟大理想，这时候可以使用 package.json 的 engines 字段来指定项目 node 版本：
"engines": {
"node": ">= 8.16.0",
"npm": ">= 6.9.0"
},需要注意的是，engines属性仅起到一个说明的作用，当用户版本不符合指定值时也不影响依赖的安装。
自定义命令（bin）
用过 vue-cli，create-react-app等脚手架的朋友们，不知道你们有没有好奇过，为什么安装这些脚手架后，就可以使用类似 vue create/create-react-app之类的命令，其实这和 package.json 中的 bin 字段有关。
bin 字段用来指定各个内部命令对应的可执行文件的位置。当package.json 提供了 bin 字段后，即相当于做了一个命令名和本地文件名的映射。
当用户安装带有 bin 字段的包时，
如果是全局安装，npm 将会使用符号链接把这些文件链接到/usr/local/node_modules/.bin/；
如果是本地安装，会链接到./node_modules/.bin/。
举个 ，如果要使用 my-app-cli 作为命令时，可以配置以下 bin 字段：
"bin": {
"my-app-cli": "./bin/cli.js"
}上面代码指定，my-app-cli 命令对应的可执行文件为 bin 子目录下的 cli.js，因此在安装了 my-app-cli 包的项目中，就可以很方便地利用 npm执行脚本：
"scripts": {
start: 'node node_modules/.bin/my-app-cli'
}咦，怎么看起来和 vue create/create-react-app之类的命令不太像？原因：
当需要 node 环境时就需要加上 node 前缀
如果加上 node 前缀，就需要指定 my-app-cli 的路径 -> node_modules/.bin，否则 node my-app-cli会去查找当前路径下的 my-app-cli.js，这样肯定是不对。
若要实现像 vue create/create-react-app之类的命令一样简便的方式，则可以在上文提到的 bin 子目录下可执行文件cli.js 中的第一行写入以下命令：
#!/usr/bin/env node
这行命令的作用是告诉系统用 node 解析，这样命令就可以简写成 my-app-cli 了。
内容来源：
https://juejin.cn/post/6844904159226003463
常用的package.json，还有这多你不知道的骚技巧 https://zhuanlan.zhihu.com/p/148795036
转载本站文章《npm包package.json字段解析》,
请注明出处：https://www.zhoulujun.cn/html/webfront/ECMAScript/nodejs/8742.html