package-lock引起的奇妙问题

前言

一直以来对于npm的印象只停留在包管理工具上，使用起来就是在dependency里加个依赖就完了，一切都很顺利，偶然间发现项目里多出了一个package-lock的文件，但好像也没有什么用，就一直忽略，直到今天遇到问题。

问题现象

测试人员今天下午提了一个bug，并贴心的配合一张图来说明，如下图所示那个图标位置偏右。

我也没多想，感觉就是一个简单的样式问题，领了bug，打开IDE启动开发环境，准备三分钟解决。

定位流程

核实问题

启动了开发环境后，就有点懵逼，咦，我这里是正常的啊，如下图所示。

于是怀疑是不是测试人员的测试环境是不是有问题，让他访问一下我的机器，也是没问题的，我访问了一下测试服务也确实存在偏右的问题。ok，那现在肯定是有问题的了，开始定位。

检查代码一致性

第一步是检查测试线的代码跟master线的代码版本是否一致，因为测试服务是由CI系统构建的，有可能是测试同学的脚本异常，导致版本不一致。但是测试线和master线的hash值完全一致，表明两者的代码是一致的。
然后打开chrome针对每个图标元素对比，测试服务和开发服务的样式，发现测试服务的样式多了一些内容，从代码层面上完全没有找到关联信息。隐隐感觉到不太乐观。

检查环境一致性

第二步就是检查测试环境和开发环境是否一致了，开发环境使用了win10，测试环境则是linux，开发环境是npm run dev启动的，测试环境是node server.js启动的。
不一致的因素很多，但是引起仅仅样式不一致这样的问题，感觉不太像。
为了排除环境因素，我也在本地使用npm run build;node server.js启动一样是没有问题的。
难道是win10跟linux之间的区别？按理来说这是有可能的，毕竟windows对于大小写不敏感，linux对于大小写敏感的梗玩了不知道多少年了。于是仔细检查了所有的文件，发现真的是不少，总不能一个一个的比对吧。灵机一动，把测试服务打好的文件，直接都发送到开发机器上，这样就保证了代码是完全一致的，如果表现不一致那么就肯定是环境问题。
但大大出乎我的预料，竟然在开发机器上也复现出了测试服务的样式偏移问题，问题100%复现了，就表明距离真相已经不远了。
再把开发机器打包出的文件和测试机器打包出的文件对比一下，发现测试机器打出的bundle.js比开发机器打成的多了一点点。于是可以肯定的是<<build阶段引入的问题>>。

再次核对文件，定位package-lock.json

这时仔细检查了.gitignore文件内容，以及本地没有被纳入版本管理的文件，发现了一个叫做package-lock.json躺在那。心里想不会吧，这玩意好几年了，也没见到有什么用。不过隐约记得2年前也出现了奇葩问题，那次把这个文件删掉了，就好了。这次又出现了类似的问题，赶紧查查这个文件到底是个什么鬼。

查阅原理

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.
This file is intended to be committed into source repositories, and serves various purposes:
Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
Provide a facility for users to “time-travel” to previous states of node_modules without having to commit the directory itself.
To facilitate greater visibility of tree changes through readable source control diffs.
And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.
One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package. It shares a format with npm-shrinkwrap.json, which is essentially the same file, but allows publication. This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages.
If both package-lock.json and npm-shrinkwrap.json are present in the root of a package, package-lock.json will be completely ignored.

npm文档说了一大堆，简单来说讲 package-lock.json负责锁定版本，是NPM5引入的特性，在package.json发生变化时自动生成，用来保证版本的唯一性。与这个文件类似的还有一个叫npm-shrinkwrap.json但不同的是package-lock.json是不能发布的，但npm-shrinkwrap.json可以。
查到这里我就很纳闷，为什么有了package.json还要一个 package-lock.json呢？于是又去检索了一番 package.json

package.json

其中最主要的是^标记只保证大版本一致，自动下载最新的版本。
顺道补了补课，

• devDependencies：用来放测试和文档之类的依赖，就是没有这些依赖代码也能正常工作。
• dependencies： 真正运行的依赖
• 版本匹配相关内容：

version Must match version exactly
version Must be greater than version
=version etc
<=version
~version “Approximately equivalent to version” See semver
^version “Compatible with version” See semver
1.2.x 1.2.0, 1.2.1, etc., but not 1.3.0
http://… See ‘URLs as Dependencies’ below
* Matches any version
“” (just an empty string) Same as *
version1 - version2 Same as >=version1 <=version2.
range1 || range2 Passes if either range1 or range2 are satisfied.
git… See ‘Git URLs as Dependencies’ below
user/repo See ‘GitHub URLs’ below
tag A specific version tagged and published as tag See npm dist-tag
path/path/path See Local Paths below

再检查一下package.json，确实antd的依赖写的是^4.4.3。

原因分析

我们依赖了4.4.3版本的antd，但写的是^符号。会自动下载4.x.x的最新版本的antd。
本来一切都没有问题， 9天前发布了4.5.0，如下图所示

这个版本做了大量的修复性工作，但是与我们的版本出现了不兼容。
于是出现了今天测试人员发现的问题。

解决问题

别看定位问题很麻烦，但解决起来却简单的很，直接把package-lock.json也提交即可。

结论

不求甚解是大敌，引以为戒。

参考

https://docs.npmjs.com/configuring-npm/package-lock-json