有同学提到说package-lock.json文件很容易产生冲突,我们不妨先放下这个问题,先来看看为什么我们需要package-lock.json.
package-lock.json简介
package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.
以上摘自官方文档,义译一下就是
package-lock.json会在npm更改node_modules目录树或者package.json时自动生成的。它准确的描述了当前项目npm包的依赖树,并且在随后的安装中会根据package-lock.json来安装,保证是相同的一个依赖树,不考虑这个过程中是否有某个依赖有小版本的更新。
这里有个很重要的点就是,package-lock.json记录的是一个依赖树,而不是你直接在package.json中的依赖项。和直接在package.json中锁死版本不一样的地方在于,package.json中只是锁死了依赖项的版本,而没有锁死依赖项的依赖的版本,这里就是变数的地方。如果不对整个依赖树做锁定,那前后编译出来的应用版本可能是不一样的,有可能开发时能正常工作,而到了线上却不能工作。
所以很明显的package-lock.json是很符合我们的诉求的。我们需要让后面每一次install都是相同的版本,打出来的包都有着相同的依赖,这对于我们项目的稳定性、前后一致性是非常重要的。
如何解决package-lock的冲突呢?
不要试图删除package-lock.json来解决一些问题,这样会破坏package-lock.json的作用。
package-lock是工具自动生成的一个文件内容,对于这种自动生成的文件最好的办法还是交由工具去处理,而不是手工一个一个的去处理产生的冲突。
在开发过程中,合并的时候如何如果出现了冲突,在merge conflicts的阶段,只需要从主分支中checkout去package-lock.json,再以此为基础,重新安装新分支中需要的依赖。
git checkout dev -- package-lock.json;
npm install lodash --save;
这样让npm自动的去维护package-lock.json。当然上面的步骤同样也适用于rebase过程。
我相信这个办法可以很好的解决package-lock.json冲突的问题,并且团队合作中,做merge或者rebase操作的人可以通过查看package.json的变更知道新安装了哪些依赖包,来重新安装,也可以很好的解决这个问题。
校验package-lock.json的正确性
在按照上面的步骤解决完package-lock.json的冲突后,code reviewer对package-lock.json的正确性需要做一次校验,按照gerrit中的说法就是verify的过程。将被review的代码拉到本地做一次npm install
,检查package-lock.json是否有modified,如果没有modify说明提交的package-lock.json是一份正确的文件。
有一个问题,package-lock.json中的resolved字段会被不同环境中的npm registry改写,这样会导致很多的冲突。所以在经过正确性校验的过程中,可能会因为本地registry的配置问题会导致package-lock.json处于modified状态。所以为了规避这个问题,需要在团队内统一npm registry,可以在项目根目录中使用.npmrc来配置项目级别的registry来进行统一。
网友评论