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

多年前的Leftpad 撤包事件使得React 、 Babel 和许多流行的npm模块都受到波及，无法正常运行。
这些受到影响的模块都引入了一个叫做 left-pad 的模块。
以下就是这十一行代码：

1. module.exports = leftpad;
2. function leftpad (str, len, ch) {
3. str = String(str);
4. var i = -1;
5. if (!ch && ch !== 0) ch = ' ';
6. len = len - str.length;
7. while (++i < len) {
8. str = ch + str;
9. }
10. return str;
11. }

复制代码

而其中的原因大概是这样：作者 Azer 写了一个叫 kik 的工具和某个公司同名了，这天公司的律师要求其删掉这个模块，把 kik 这个名字“让”给他们，作者不答应，律师就直接找 NPM 了，而 NPM 未经作者同意就把包的权限转移给了这家公司。于是，Azer 一怒冲冠，将他所有的 NPM 包全部删掉了。
有意思的是，社区中许多的模块都选择引入这个十一行的模块，而不是花上两分钟的时间自己去实现这个简单的字符串填充功能。
这不是npm包管理第一次出问题，也不会是最后一次。
Leftpad撤包事件、event-stream投毒事件、Ant Design彩蛋时间，使得我们不得不开始重新思考npm生态真的存在的问题，甚至去问自己：我们是不是早已忘记该如何好好地编程？

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

这种过度依赖其他npm模块的做法是不是解决问题的正确方式呢？现在，一个空白项目模板一装好就要引入两万八千多个文件、依赖成百上千个其他的npm模块。这太疯狂了、而且过度复杂。
那么我们可以做些什么？把命运掌握在自己手里

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

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

1. A@0.1.0
2. └─┬ B@0.0.1  
3.   └── 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的命令来解决这个问题：

1. NAME
2.   npm-shrinkwrap -- Lock down dependency versions
4. SYNOPSIS
5.   npm shrinkwrap
7. DESCRIPTION
8.   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 文件内容大概是下面这样：

1. {
2.     "name": "A",
3.     "dependencies": {
4.         "B": {
5.             "version": "0.0.1",
6.             "resolved": "http://registry.npmjs.com/B-0.0.1.tgz",
7.             "dependencies": {
8.                 "C": {  
9.                  "version": "0.0.1",
10.                  "resolved": "http://registry.npmjs.com/C-0.0.1.tgz"
11.           }
12.             }
13.         }
14.     }
15. }

复制代码

然后，当我们执行 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 命令：

1. "scripts": {
2.   "pack": "npm shrinkwrap & shrinkpack ."
3. }

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！