package.json
俗称 依赖配置文件(我自己取的名),最主要的作用就是,管理项目中所用到的依赖。它本身的作用是为 node.js 模块服务的,模块有很多属性,为了描述模块的特性,package.json
也被称作模块的 描述文件
。
name version
name
和 version
是 package.json
中最重要的两个属性,而且是必填的。这两个属性一起就形成了 npm 模块唯一标识符。分别表示 模块的 名称 和 版本。名称一般不会变,版本会随着模块的修改而更新变动。
description keywords
这两个字段都是用来在 npm
官网上搜索的, 区别是一个是字符串, 一个是字符串数组。
dependencies devDependencies
这两个属性,都是用来记录项目中所用到的依赖。区别是,一个是用来记录开发环境所用的依赖,一个是记录生产环境所用到的依赖。
比如,对于大多数前端项目来说,gulp
等构件工具及插件,可能只在开发环境中使用,而在生产环境只关心最终生成的 dist
文件,所以,gul
p 等插件 就应该放在 devDependencies
下。
通过 npm i xxx -save
、npm i xxx -s
、yarn add xxx -S
安装的依赖会添加到 dependencies
下;
通过 npm i xxx -save-dev
、npm i xxx -d
、yarn add xxx -D
安装的依赖会添加到 devDependencies
下;
peerDependencies
可以让宿主环境拥有某个特定版本的依赖
前提:项目X
依赖 模块A
, 模块A
依赖 模块B
情况一:如果 模块B
定义在 模块A
的 dependencies
字段中
结果:模块B
只能被 模块A 引用
;
可能的好处:假如 项目X 也依赖 模块B,版本不一样,则可以互不干扰。
可能的坏处:假如 项目X 也依赖 模块B,且版本一样,则会有两个一模一样的 模块B
项目X
└──node_modules/
└── 模块A
└──node_modules/
└── 模块B
情况二:如果 模块B
定义在 模块A
的 peerDependencies
字段中
结果:项目X
也会下载 或 检查 模块b
的版本。
可能的好处:假如 项目X 也依赖 模块B,版本不一样,则会在控制台以警告的形式提示版本问题。
可能的坏处:假如 项目X 也依赖 模块B,且版本一样,只用下载一遍。
项目X
└──node_modules/
├── 模块a
└── 模块b
结论:定义在 peerDependencies
中的依赖,在宿主环境中,也会被下载 或 被检查版本。
files
files
是一个包含项目中的文件的数组。如果命名了一个文件夹,那也会包含文件夹中的文件。(除非被其他条件忽略了 .npmignore .gitignore)
在 npm publish
的时候,会依据这个配置 上传你的文件。
scripts
scripts
是一个由脚本命令组成的 kye value 对象。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。