多年前的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 里面写死版本号，但是这解决不了深度依赖的问题。我们来看个例子。 假设有下面这样的依赖：

A@0.1.0 
└─┬ B@0.0.1  
  └── C@0.0.1

A 模块依赖了 B 模块，B 模块又依赖了 C 模块。我们可以将 B 模块的依赖写死成 0.0.1 版本，但是如果 B 模块对 C 模块的依赖写的是 C@0.0.1，会怎样？

这时候 C 模块更新到了 0.0.2 版本，虽然我们安装的 B 模块是 B@0.0.1，但是安装的 C 模块却是 C@0.0.2。如果不巧这个 C@0.0.2 刚好有 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，再也不会突然装上什么 C@0.0.2 了，依赖里面的模块版本都是我们验证、测试后的版本，让人安心。

注：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 ."
}