npm包的更新说明，你还敢不看吗

前言

平时工作少不了依赖一些第三方的npm包，站在各位大牛的肩膀上来更好的写bug，此外还可以学习各位大佬们的各种设计思路和优雅实现。不过npm包虽好，但使用之前也要多加甄别，特别是相同包的不同版本之间的差别，可能一不小心，原本用的飞起的轮子就会让我们笑不出来。下面用两次惨痛的线上问题来给大家提个醒。

版本依赖符号

在描述问题之前，先谈一下npm的包管理控制。

假设我们依赖一个npm包 a 常见的依赖符号有下面这么几种

{

"dependencies": {

  "a":"5.6.1",

  "a":">=5.6.1",

  "a":">5.6.1",

  "a":"<=5.6.1",

  "a":"<5.6.1",

  "a":"~5.6.1",

  "a":"^5.6.1"

}

}

我们安装的npm包依赖有大概下面这么几种：

version 匹配具体版本例如：a:5.6.1
|>=|<|<= version 大于或者小于5.6.1
~version 大致相当于当前版本即 5.6.X 均可以 5.7.1不可以
^version 兼容版本兼容的是中间的版本，例如5.7.X不包括 6.X.X

详细区别请查看

根据上面的安装标识，npm会默认去拉去符合规定的最新版本。

当我们执行npm i 时默认的版本依赖关系是"a":"^5.6.1"

npm i a -s //默认安装的依赖符号是 "a":"^5.6.1"

上面是npm的版本控制规范，有规范也要我们去遵循才可以生效。

开发者版本控制

我们发布npm包的时候，版本标识是package.json中的version

"version": "0.0.1"

一般来说对于测试版本，都是0.X.X的版本(当然也可以有例外，例如react，最高到0.14.X，突然来了个15.X.X)

成熟版本会从1.X.X开始。

如果有bug或者功能更新的时候，可不能随便更新，要根据对使用者的影响程度来进行版本更新。

版本更新策略

从我们团队来说版本更新策略如下：

bugfix 原有功能和api无变动

最后一位小版本更新
功能更新，新增api等，但是老版本依旧可以使用

中间一位版本更新
不兼容更新，老版本无法使用

最前面的大版本升级

更复杂一点的可以通过tag来控制不同包具体可以参考https://cnodejs.org/topic/537b47d1cbcc39634983b739来了解

使用者

结合前面提到的，npm 默认的兼容版本安装，成熟npm包来说，更新策略一般都是考虑使用者的。

会进行比较严谨的版本控制，但是我们新项目使用的时候，如果觉得老的包有用，直接npm i 之前可要思量一下，是否进行了打的版本升级。

问题示例

一、query-string 6.x版本不支持低版本

问题描述

上线一个月左右的一个项目，突然接到反馈，某个页面正常渲染之后，无法选中某个某个模块。

问题定位

问题复现

接到反馈之后，立即拿起手边的手机进行复现，心里还说这么明显的问题竟然发生了，赶紧分分钟干掉。

结果发现手边的手机都无法复现这种情况

app版本

这时候怀疑是不是app版本问题，试着让用户升级下app。

结果发现依旧存在相同问题

确认问题机型

这时候询问发现机型为oppo，没有仔细去看具体型号。

赶紧拿了个oppo r17测试机，发现依然不存在相关问题。

是否网络问题

因为使用的是公司内网，切换到手机4g，依然无法复现。

操作系统版本

这时候怀疑是旧版本不兼容最新语法，不过我们的js都是经过处理的，应该不会存在，不过还是确认了下用户操作系统，安卓4.6

复现

因为身边手机版本都较高，无法复现，不复现就很难定位。这时候想起来我司有个云真机平台，终于找到了个低版本的oppo，app运行都有点卡的那种。。。上面终于复现了。赶紧去调试，发现点击的时候报错:

Uncaught SyntaxError: Use of const in strict mode.

这下确认是es6没有被转义的问题了

问题解决

不过这里还有点疑问，我们项目本身将src下的源码进行了处理的。如果说没有成功，那么多用到const的地方，应该一开始就报错。这下就让我我有点头疼了。

仔细想了想，可能是第三方npm包没有经过转义处理，不过引了那么多的包，确定还是太难了。webpack打包之后的代码生产环境下是压缩的，简直不能看。

本地打包

还好webpck4提供了不同的mode方式，可以直接使用 --mode development指定打包，这样是没有压缩过的。

对比发现，const出现在query-string相关逻辑中，直接本地打开查看，发现就是其6.X的版本有要求。