Leftpad事件 我们是不是早已忘记该如何好好地编程?

多年前的Leftpad 撤包事件使得React 、 Babel 和许多流行的npm模块都受到波及,无法正常运行。

这些受到影响的模块都引入了一个叫做 left-pad 的模块。
以下就是这十一行代码:

module.exports = leftpad;
function leftpad (str, len, ch) {
str = String(str);
var i = -1;
if (!ch && ch !== 0) ch = ' ';
len = len - str.length;
while (++i < len) {
str = ch + str;
}
return str;
}

而其中的原因大概是这样:作者 Azer 写了一个叫 kik 的工具和某个公司同名了,这天公司的律师要求其删掉这个模块,把 kik 这个名字“让”给他们,作者不答应,律师就直接找 NPM 了,而 NPM 未经作者同意就把包的权限转移给了这家公司。于是,Azer 一怒冲冠,将他所有的 NPM 包全部删掉了。

有意思的是,社区中许多的模块都选择引入这个十一行的模块,而不是花上两分钟的时间自己去实现这个简单的字符串填充功能。

这不是npm包管理第一次出问题,也不会是最后一次。

Leftpad撤包事件、event-stream投毒事件、Ant Design彩蛋时间,使得我们不得不开始重新思考npm生态真的存在的问题,甚至去问自己:我们是不是早已忘记该如何好好地编程?

  • NPM模块粒度
  • 代码风格
  • 代码质量/效率
  • 过度依赖

这种过度依赖其他npm模块的做法是不是解决问题的正确方式呢?现在,一个空白项目模板一装好就要引入两万八千多个文件、依赖成百上千个其他的npm模块。这太疯狂了、而且过度复杂。

那么我们可以做些什么?把命运掌握在自己手里

  • 在发布前“冻结”依赖模块的版本号。这让我们对安装的依赖有信心,依赖模块的版本都是我们验证、测试过的。
  • 在发布前“打包”依赖模块到自己项目。这让我们可以坦然面对我们依赖的某个模块“没有了”这样的囧境。

冻结依赖模块:

冻结依赖模块的版本号最简单的办法就是直接在 package.json 里面写死版本号,但是这解决不了深度依赖的问题。我们来看个例子。 假设有下面这样的依赖:

[email protected] 
└─┬ [email protected]  
  └── [email protected]

A 模块依赖了 B 模块,B 模块又依赖了 C 模块。我们可以将 B 模块的依赖写死成 0.0.1 版本,但是如果 B 模块对 C 模块的依赖写的是 [email protected],会怎样?

这时候 C 模块更新到了 0.0.2 版本,虽然我们安装的 B 模块是 [email protected],但是安装的 C 模块却是 [email protected]。如果不巧这个 [email protected] 刚好有 bug,那我们的模块很有可能就不能正常工作了。 实际上,NPM 提供了一个叫做npm shrinkwrap的命令来解决这个问题:

NAME
  npm-shrinkwrap -- Lock down dependency versions

SYNOPSIS
  npm shrinkwrap

DESCRIPTION
  This  command  locks down the versions of a package's dependencies so that you can control exactly which versions of each  dependency  will be used when your package is installed.

这条命令会根据目前我们 node_modules 目录下的模块来生成一份“冻结”住的模块依赖(npm-shrinkwrap.json)。

还是上面的例子,我们在模块 A 的根目录执行 npm shrinkwrap 后,生成的 npm-shrinkwrap.json 文件内容大概是下面这样:

{
    "name": "A",
    "dependencies": {
        "B": {
            "version": "0.0.1",
            "resolved": "http://registry.npmjs.com/B-0.0.1.tgz",
            "dependencies": {
                "C": {  
                 "version": "0.0.1",
                 "resolved": "http://registry.npmjs.com/C-0.0.1.tgz"
          }
            }
        }
    }
}

然后,当我们执行 npm install 时,依赖查找的“来源”不再是 package.json,而是我们生成的 npm-shrinkwrap.json,再也不会突然装上什么 [email protected] 了,依赖里面的模块版本都是我们验证、测试后的版本,让人安心。

注:npm shrinkwrap 默认只会生成 dependencies 的依赖,不会生成 devDependencies 的依赖,如果你真的需要,可以加 --dev 参数。

打包依赖模块:

我们解决了依赖模块版本号的问题,但是每次安装时其实还是会去 NPM 的 registry 获取模块的 tgz 包然后进行安装。我们需要将这些依赖都打包进我们的项目。这可能会带来一些问题(比如:项目体积的增大),但是好处也是显而易见的。

上面生成的 npm-shrinkwrap.json 里面有个 resolved 字段,表示模块所在的位置,实际上这个字段完全可以写一个文件路径。所以,我们可以递归的遍历 npm-shrinkwrap.json 文件,将所有的 tgz 包先下载到我们项目的某个目录,然后改写 resolved 字段为对应的文件路径。这样的功能有开发者已经实现了,我们可以直接享用:https://github.com/JamieMason/shrinkpack

于是,我们以后再进行 npm install --loglevel=http 时会发现依赖模块的安装根本没有网络请求了(因为依赖都在我们自己的仓库里了嘛)。

可能有人会说,为啥不直接把 node_modules 目录提交进仓库算了?原因主要是这样:

  • 有些模块需要编译,编译是和环境有关的,你当前的环境编译可用,其他环境直接使用该模块不一定能用。
  • node_modules 目录里面啥东西都有,太凌乱,很容易把提交给搅乱。diff 时突然 diff 出 node_modules 下的源代码、README,你应该不想这样吧?

只存储模块的 tgz 包,安装编译的过程交给 NPM 命令更明智。

新方式

于是,现在我们使用 NPM 模块的正确姿势应该是这样了:

  1. 本地安装、更新需要的模块,测试、验证
  2. 执行 npm shrinkwrap 将依赖模块的版本冻结
  3. 执行 shrinkpack . 将依赖模块打包进仓库
  4. 提交代码(注意要将 npm-shrinkwrap.json 和 node_shrinkpack 一起提交哦)
  5. 发布模块或者部署应用

如果你觉得这样很繁琐,可以定义一个 NPM 命令:

"scripts": {
  "pack": "npm shrinkwrap & shrinkpack ."
}

热门相关:无量真仙   寂静王冠   薄先生,情不由己   危险的嗜好   寂静王冠