这些受到影响的模块都引入了一个叫做 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包管理第一次出问题，也不会是最后一次。
我们是不是早已忘记该如何好好地编程？
- NPM模块粒度
- 代码风格
- 代码质量/效率
- 过度依赖
那么我们可以做些什么？把命运掌握在自己手里
- 在发布前“冻结”依赖模块的版本号。这让我们对安装的依赖有信心，依赖模块的版本都是我们验证、测试过的。
- 在发布前“打包”依赖模块到自己项目。这让我们可以坦然面对我们依赖的某个模块“没有了”这样的囧境。
冻结依赖模块：
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，会怎样？
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）。
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-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，你应该不想这样吧？
新方式
- 本地安装、更新需要的模块，测试、验证
- 执行
npm shrinkwrap将依赖模块的版本冻结 - 执行
shrinkpack .将依赖模块打包进仓库 - 提交代码（注意要将
npm-shrinkwrap.json和node_shrinkpack一起提交哦） - 发布模块或者部署应用
如果你觉得这样很繁琐，可以定义一个 NPM 命令：
"scripts": {
"pack": "npm shrinkwrap & shrinkpack ."
}