美文网首页
依赖包版本锁 or 不锁?这个问题吵起架来拉都拉不住...

依赖包版本锁 or 不锁?这个问题吵起架来拉都拉不住...

作者: 源大侠 | 来源:发表于2023-04-23 17:30 被阅读0次

    这个问题聊好多年了,双方观点旗帜鲜明,各有各的道理,搞场辩论赛一定很精彩。最近由于 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 不够完美?因为间接依赖没锁。

    相关文章

      网友评论

          本文标题:依赖包版本锁 or 不锁?这个问题吵起架来拉都拉不住...

          本文链接:https://www.haomeiwen.com/subject/nwryjdtx.html