这个问题聊好多年了，双方观点旗帜鲜明，各有各的道理，搞场辩论赛一定很精彩。最近由于 antd 的一个 bug 版本被重新谈起，然而一直没有最优解。
假如不锁版本，可能睡一晚产品发布就挂了，怪谁，自己人的开源项目还可以找找，react 的锅总不能飞美国去 Meta 公司找 Dan 吧。假如锁了版本，1 不能跟进安全修复类 bug，2 时间久了升不动也不愿升，筑起技术债，给后人留屎山。
除了稳定性，这里还有人性的问题，就是谁该对此负责。因为三方问题背个故障，谁都会觉得冤枉。相反如果有人说别锁了，我对故障负责，那大部分人也就都不会有意见了，爱锁不锁。
聊这个话题，还有两个点需要提前对齐知识储备的。1、依赖分 node 和 browser，两者的解法不同，后者需要考虑 tree-shaking、补丁、产物尺寸等 2、依赖分直接依赖和间接依赖，锁直接依赖只能解部分问题。
问题的根源是 semver。理想的 semver 是 break.feat.bugfix，现实的 semver 是 break.break.break。发 break 的 bugfix 版本是社区的常规操作。但是在责怪库作者之前，有些场景要除外，比如使用了私有 API、通过 HACK 的方式关闭某些功能，依赖组件库内部的 DOM 结构和 CSS 类名，更新后挂了，这就只能怪自己了。
是问题就有解，社区已有不少。临时的比如 cnpm 提供的 bug-versions，npm 提供的 resolutions，侵入式改代码的 patch-package 等；长期的比如 npm、yarn 和 pnpm 具备的 lock 能力，tnpm/cnpm 目前暂不支持，但可以用 yarn mode。
内部解还有 DEVOPTS 平台的迭代锁，作为锁与不锁之间的端水大师，在整体不锁的策略下，确保迭代内是稳定的。能解部分问题，但锁支持者应该是不会满意的，因为跨了迭代就不稳定了，而建迭代又是高频操作。
那有没有两全的办法？既要稳定，又要更新，还有有人负责。有！一个思路是「中间商锁依赖，定期更新，并对此负责」。框架是开发者的倒数第二道防线，自然而然就应该是这个中间商。
前面说依赖分 node 和 browser。node 部分已经这么做了，umi 锁依赖，定期更新，出问题了 umi 负责。大家用 umi 3 或者 bigfish 3 应该很少再有遇到因三方 node 库比如 babel、webpack 更新导致的问题。比如之前的 coa 挂马事件，就完全伤不到我们。
背后主要是 umi 层对依赖做了彻底锁，包含间接依赖，通过预打包依赖的方式，就算再过 10 年，也不会出现因 node 依赖更新导致 umi 挂的情况。此外还有些细节，比如 babel runtime 和 polyfill 等 browser 依赖的锁定等。
能套用到 browser 依赖吗？有点困难。1、彻底锁的问题，browser 要考虑尺寸，预打包会让 tree-shaking 失效 2、回归的成本问题，比如 antd 库的回归，除了人肉回归大量项目，没想到万全的方法 3、不像 node 库大部分问题在流程中就能发现，browser 库直接影响线上，所以风险更高。
问题 1 是工程问题，大概率是有解的，现在没有解再过几年来看看可能就有了，我想到的是 importmaps 锁，借助 esmi 服务，可解尺寸问题；问题 2 需要人，群里得知 LOWCODE 平台维护的 xxx-antd 每次迭代 N 人日保障，虽不能完全确保没问题，但相比盲升应该是更是靠谱的；群里还有聊到灰度的方案，解法是加延迟，让一个群体或不重要的业务先踩坑，避免对重要业务的影响。
所以 importmaps 锁 + 有人担保的类 xxx-antd 中间依赖 + 灰度可能是 browser 依赖的完美解。至于 procode 为啥直接用 xxx-antd 不够完美？因为间接依赖没锁。
网友评论