原文链接：依赖版本锁不锁
本来只是看下依赖预打包是怎么回事，然后被迫又重新读了这篇文章。有几点值得思考的
关于依赖版本到底锁不锁，锁？如何保持更新，不锁？如何保持稳定
中间商锁依赖，定期更新，并对此负责
1、 依赖分为node依赖和browser依赖，其实我一直区分不了这两者。后者考虑tree-sharking、产物尺寸等
2、 依赖从一个维度分为间接依赖和直接依赖，锁直接依赖只能解决部分问题
3、目前社区已有的解决方案
1）cnpm提供的bug-versions
2）npm提供的resolutions
- 侵入式代码patch-package
patch-package，这个点学到了。因为我在实际工作中也碰到过，之前是forked的或者拷贝源码到本地，如今学到这一招patch-package。
以下翻译自patch-package
patch-package
Patch 相比 forked，好处在于
-
有时forked是需要额外的构建步骤
-
当依赖发生变化的时候，会告诉你一个红色的提示，让你检查你的修复是否依然有效
-
将你的补丁与依赖它们的代码放在一起。
-
patches 可以是正常review过程中的一部分，但是forked 不会
什么时候使用forked
-
变化太大了无法原地开发
-
这种变化对他人有用
-
你可以创建一个合适的pr
Patch 有危险吗
不会.有几个点必须要记住
-
在有没有patch文件的分支切换时，很容易忘记运行
yarnornpm -
如果长期的补丁影响到一个定期更新的代码区域，而你也想定期更新软件包，那么维护的成本就会很高。
-
大的semantic变化很难review，让它们小而且明显，或者添加注释
-
改变也会影响其他未触及的软件包的行为。通常情况下，这种情况会很明显，而且往往是希望如此，但还是要小心。（这句翻译好生硬，西巴）
umi本身自己是怎么解决的
背后主要是uⅱ层对依赖做了彻底锁，包含间接依赖，通过预打包依赖的方式，就算再过10年，也不会出现因node依赖更新导致umi挂的情况。此外还有些细节，比如babel runtime和polyfill等browser依赖的锁定等。
###能套用到browser吗？
不能。因为预打包会让tree-shaking失效。node库大部分能在流程中发现，但是browser库必须要到线上才能发现。
所以importmaps锁+有人担保的类xx-antd中间依赖+灰度可能是browser依赖的完美解。至于为什么procode为啥直接用x-antd不完美？因为间接依赖没锁。
哎，学习学着学着就发散了
