package.json|package.json 和 package-lock.json 的作用
package.json是什么?
npm安装package.json时 直接转到当前项目目录下用命令npm install 或npm install --save-dev安装即可,自动将package.json中的模块安装到node-modules文件夹下。
package.json就是管理你本地安装的npm包,用于定义了这个项目所需要的各种模块,以及项目的配置信息(比如名称、版本、许可证等元数据)。一个package.json文件可以做如下事情:
展示项目所依赖的npm包
允许你指定一个包的版本[范围]
让你建立起稳定,意味着你可以更好的与其他开发者共享
注意:npm init 时,用户需回答一些问题,然后在当前目录生成一个基本的package.json文件。所有问题之中,只有项目名称(name)和项目版本(version)是必填的,其他都是选填的。
【package.json|package.json 和 package-lock.json 的作用】package.json字段说明
1、name
包的名称,必须是唯一的,由小写英文字母、数字和下划线组成,不能包含空格
2、version
项目版本号,符合语义化版本识别规范的版本字符串
3、description
项目描述,项目的简要说明
4、keywords
{Array}关键词数组,便于用户搜索到我们的项目。
5、homepage
用于定义项目url主页
6、bugs
提交bug的地址,项目问题反馈的Url或email配置,如:
1
2
3
4
{
“url” : “https://github.com/issues“,
“email” : “project@hostname.com”
}
7、license
项目许可证,让使用者知道是如何被允许使用此项目。默认是”ISC”
8、author
定义该项目的作者。
9、private
代表npm是否发布该项目。如果设置为true, 那么npm会拒绝发布它
10、scripts
指定了运行脚本命令的npm命令行缩写,比如start指定了运行npm run start时,所要执行的命令。下面的设置指定了npm run dev、npm run bulid、npm run unit、npm run test、npm run lint时,所要执行的命令。如下:
1
2
3
4
5
6
7
“scripts”: {
“dev”: “node build/dev-server.js”,
“build”: “node build/build.js”,
“unit”: “cross-env BABEL_ENV=test karma start test/unit/karma.conf.js --single-run”,
“test”: “npm run unit”,
“lint”: “eslint --ext .js,.vue src test/unit/specs”
},
11、dependencies,devDependencies
dependencies和devDependencies两项,分别指定了项目运行所依赖的模块、项目开发所需要的模块。它们都指向一个对象,该对象的各个成员,分别由模块名和对应的版本要去组成,表示依赖的模块及其版本范围
其实用一句话来概括很简单,就是锁定安装时的包的版本号,并且需要上传到git,以保证其他人在npm install时大家的依赖能保证一致。
根据官方文档,这个package-lock.json 是在 npm install
时候生成一份文件,用以记录当前状态下实际安装的各个npm package的具体来源和版本号。
它有什么用呢?因为npm是一个用于管理package之间依赖关系的管理器,它允许开发者在pacakge.json中间标出自己项目对npm各库包的依赖。你可以选择以如下方式来标明自己所需要库包的版本
这里举个例子:
“dependencies”: {
“@types/node”: “^8.0.33”,
},
这里面的 向上标号^是定义了向后(新)兼容依赖,指如果 types/node的版本是超过8.0.33,并在大版本号(8)上相同,就允许下载最新版本的 types/node库包,例如实际上可能运行npm install时候下载的具体版本是8.0.35。波浪号
大多数情况这种向新兼容依赖下载最新库包的时候都没有问题,可是因为npm是开源世界,各库包的版本语义可能并不相同,有的库包开发者并不遵守严格这一原则:相同大版本号的同一个库包,其接口符合兼容要求。这时候用户就很头疼了:在完全相同的一个nodejs的代码库,在不同时间或者不同npm下载源之下,下到的各依赖库包版本可能有所不同,因此其依赖库包行为特征也不同有时候甚至完全不兼容。
因此npm最新的版本就开始提供自动生成package-lock.json功能,为的是让开发者知道只要你保存了源文件,到一个新的机器上、或者新的下载源,只要按照这个package-lock.json所标示的具体版本下载依赖库包,就能确保所有库包与你上次安装的完全一样。
原来package.json文件只能锁定大版本,也就是版本号的第一位,并不能锁定后面的小版本,你每次npm install都是拉取的该大版本下的最新的版本,为了稳定性考虑我们几乎是不敢随意升级依赖包的,这将导致多出来很多工作量,测试/适配等,所以package-lock.json文件出来了,当你每次安装一个依赖的时候就锁定在你安装的这个版本。
那如果我们安装时的包有bug,后面需要更新怎么办?
在以前可能就是直接改package.json里面的版本,然后再npm install了,但是5版本后就不支持这样做了,因为版本已经锁定在package-lock.json里了,所以我们只能npm install xxx@x.x.x 这样去更新我们的依赖,然后package-lock.json也能随之更新。
假如我已经安装了jquery 2.1.4这个版本,从git更新了package.json和package-lock.json,我npm install能覆盖掉node_modules里面的依赖吗?
其实我也有这个疑问,所以做了测试,在直接更新package.json和package-loc.json这两个文件后,npm install是可以直接覆盖掉原先的版本的,所以在协作开发时,这两个文件如果有更新,你的开发环境应该npm install一下才对。
推荐阅读
- 急于表达——往往欲速则不达
- 第三节|第三节 快乐和幸福(12)
- 20170612时间和注意力开销记录
- 2.6|2.6 Photoshop操作步骤的撤消和重做 [Ps教程]
- 对称加密和非对称加密的区别
- 眼光要放高远
- 樱花雨
- 前任
- 2020-04-07vue中Axios的封装和API接口的管理
- 烦恼和幸福