善用 npm alias 特性安装替换用包

“替代包” 的这个特性从 [email protected] 开始提供（yarn 好像初版就有了？）。

比如我不爽 tape 包引入了一大堆没必要的 polyfill，而作者却不希望做出应对：

[email protected]/tape#444

The size of node_modules is irrelevant; more deps is better; this is a test framework so bundle size is irrelevant; I’m not sure what benefit there would be from inlining it.

译：node_modules 的大小与此[使用 string.prototype.trim]无关；依赖用得越多越好；这是一个测试框架所以打包后的大小与此无关；我不认为将其内置[减少这个依赖]会带来什么好处。

… 很不爽有木有?! 你用一个连 node 0.10 就开始有的函数都要给他引入个 polyfill？^[1]

反正开源，不合口味就自己造呗。

一通操作后就可以发自己的包了：npm:@jixun/tape

然后，就可以在项目安装这个“替代包”了：

$ npm install [email protected]:@jixun/tape --save-dev

※ 替换包的 .bin 不能正常使用，于是又加了个 @jixun/tape-bin。

毕竟是直接“顶替”掉原本 tape 包的目录且双方的 API 兼容，理论上不需要更改任何业务代码。

直接在项目里拿新装的测试框架跑跑看：

$ npm run test

嘿，全都成功了（当然，也有可能被我改坏成全部都显示成通过了w）。

适合的场景：

• 不想部署一个私有的包仓库，或没有条件
• 直接 "hack" 出一个能用/合适/符合自己口味的版本
• 直接用一个 API 兼容的替代包替换掉现有的包的实现（如利用 lodash 替换 underscore）
• 同时存留多版本（如 npm i [email protected]:[email protected] [email protected]:[email protected]）
• 希望精简依赖，不希望特地给特别老的不支援的环境提供支持。

patch-package 也挺好用（比如强行让 express 支持 async 中间件和处理函数），但得安装到本地后才会开始进行补丁。

注解

^1 并不是越多越好，而是包含的包越多那么可能引入的问题也越多。现在很多包是越写越散了，甚至还有一两行代码的包，代码质量也是参差不齐。假设某个没人维护的依赖的依赖的依赖的…依赖发现了问题，那么引入这么些依赖的包都将会产生潜在的问题。当然，这也只是我个人的见解罢了。