多年前的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 模块的正确姿势应该是这样了：
- 本地安装、更新需要的模块，测试、验证
- 执行
npm shrinkwrap
将依赖模块的版本冻结
- 执行
shrinkpack .
将依赖模块打包进仓库
- 提交代码（注意要将
npm-shrinkwrap.json
和
node_shrinkpack
一起提交哦）
- 发布模块或者部署应用
如果你觉得这样很繁琐，可以定义一个 NPM 命令：
"scripts": {
"pack": "npm shrinkwrap & shrinkpack ."
}
