antd 升级方案

[benjycui]

虽然现在 antd 已经发布到 2.x 了，但是还有大量的系统处于 0.x.y 1.x，并且每次发布不兼容版本都会加剧版本碎片化的问题。明显我们没有足够的人手维护多版本，这样会导致使用旧版的用户无法享受 bugfix 和最新的特性。

版本碎片化的原因在于不兼容升级成本较高，主要为以下两个成本：

• 业务代码修改。
• 相应的功能回归测试。

因为这两个步骤现在主要都是人工完成，所以如果能够自动化完成，就能降低升级成本，并相应缓解版本碎片化的问题。

代码修改的成本可以通过 codemod 自动化完成来降低成本，不过现在的问题是 antd 小组并没有人手去写这些脚本。

功能回归测试需要有一个官方推荐的自动化测试方案？社区可以自行选择自动化测试方案，但是内部应该要有推荐的方案，并建议加入到学院的课程中：

• macaca
• jest
• ava
• ...

---

P.S. fit 这种打散各 UI 组件的方案，虽然表面上可以逐个组件的升级，但是如果使用的 UI 组件分别依赖了同一依赖的不兼容版本，也是得一起升级的。并且这样依赖管理会变得复杂，与现在要降低 antd 及相关配套门槛的目标不符。

[afc163]

自动化测试方案不靠谱，业务线不可能有精力去写测试用例。

[yesmeck]

有没有调查过“大量的系统处于 0.x.y 1.x”为什么不升级呢？

[benjycui]

ding 了业务线的同学。

cc @RaoHai @ddcat1115 @yiminghe

[RaoHai]

@yesmeck

1. 不知道升级了有没有问题，因为赶进度 / 怕升级出问题了搞不定影响进度 / 测试没有时间测 所以先放着。
2. 难以回归。组件的 props 改动倒是小问题，就怕 callback 参数改了，很难测。
3. 项目中一些用法不规范，导致升级之后出现样式问题。典型例子是之前 FormItem，用 label 空格，然后设置 labelCol 来做靠右提交按钮。后来 label 统一加了冒号之后不能用了，全得改成 wrapperCol 的 offset 写法。另一个栗子是手头上一个项目，几十个 Form 用了 ValueMixin 。。。

[carlos121493]

组件升级的问题

• 1.业务线中使用单页，当单页数量特别大时难以回归。
• 2.业务线中账号权限不统一，没有一个统一回归的账号，需要多个账户不同业务团队开发中测试。
• 3.非break功能的版本升级回归已经很困难，更难break功能的1.x => 2.x的升级。
• 4.回归风险太大，故障由升级同学背难以推进，业务随时变动，mock数据尚不完整，测试回归代码不好写。

[leejaen]

今天升级项目到2.3.0，控制台无限循环警告信息，导致项目崩溃……
整个项目有几十个form，每个form的form.item之前的用法几乎都是 getFieldProps、setState、defaultValue，全部改成getFieldDecorator也是醉了，在2.2.1版本里还只是单调warn，现在直接无限循环告警项目直接崩溃。本次的升级成本真的好大

[leejaen]

两点建议：1. 今后有类似本次非常大的升级时，可不可以先开发释放出升级工具，以帮助旧版本用户平滑升级？2. 在无升级工具而且不影响新版本功能特性的情况下，先暂时先允许兼容旧版本一段时间，给用户足够的时间fit新版本。

[yesmeck]

我觉 antd 现在能做的：

1. 尽量在发布新版本的时候对于 API 的变动提供 codemod；
2. 增加测试覆盖率，避免回归；
3. API 变动前先给一段时间的警告（这个其实已经在做了）。

[warmhug]

关注。。 业务线升级组件库是难以解决的痛。。 组件库升级节奏慢一点，兼容的代码多一点、break change 少一点，就像浏览器升级一样，可能还是最好解法

[benjycui]

在2.2.1版本里还只是单调warn，现在直接无限循环告警项目直接崩溃。

麻烦开个新的 issue，提供可重现 demo，2.3.0 我修改了 warning 的逻辑，应该是合并了相同的 warning 才对。。。

Please provide a re-producible demo: http://codepen.io/benjycui/pen/KgPZrE?editors=001

[benjycui]

重现了。。现在 fixing

[afc163]

@leejaen

getFieldProps 的用法是在 2.x 会一直保持兼容的。无限循环的 warning 应该是个 bug @benjycui 应该在改了。

[leejaen]

效率好高，多谢！

[infeng]

对于我，升级不及时的原因主要有几个：

1. 业务代码量大，一旦出现不兼容升级，工作量很大
2. 一些组件使用不规范，在升级后容易出现问题
3. 升级前需要对各个组件进行测试，例如2.0.0之后的几个版本，DatePicker都出现了不同程度的bug，导致无法在正式环境使用

之后想引用自动化测试，还没找到比较好的方案

[ddcat1115]

业务线中我只遇到过两次主动想升级的，一是有绕不过去的bug了，二是想要的新特性老版本里没有，自己开发成本又很高。中后台这边大部分系统的展示要求都不复杂，就是那几个常用组件翻来覆去用，也没有什么大问题，所以升级成本是很重要的一方面，另一方面是人家本来就没有这个需求 😢 ，不会主动想着升级

[codering]

没办法，得兼容IE8。。。。

[ascoders]

单个组件发布，如果组件之间没有依赖，可以说是完美的解决方案。有依赖时，只要保证组件的隔离性，是可以多版本共存的（说我不想装两个不同版本的组件的人 you are the winner）。

当然版本升级问题本质是无法解决的，个人建议，是不要指望业务升级，发布新版本时尽量升级 major 版，bug修复直接打补丁就行，业务固定版本是最稳妥的，毕竟业务线接盘侠居多，谁也不想改一个文字，造成版本升级的未知问题。

[batouy]

@ascoders 看你提到打补丁的方式，不是很明了具体怎么做。比如我们现在项目用的antd版本是1.11.0，正好遇上了#2701这个问题，请问应该怎么打补丁？感谢！

[ascoders]

@batouy

我说的补丁是组件拆开发布时，给有 bug 的组件发布一个 patch 版本，比如 1.0.0 升级到 1.0.1，这样你用到的话只要升级下小版本号即可。

如果一个组件有个不兼容改动，就给他发布 major 版本，然后给依赖他的组件发布个 patch 版本（因为可能依赖他的组件也会有相应修正），这样对于他自己是不兼容改动升级了大版本号，而父级发布只为了兼容他而升级了小版本号，这种方式应该是最稳妥的了。

[benjycui]

简单说两句。

一个系统升级与否，是由两个变量决定的，升级成本 和 升级意愿，只有在 升级意愿 大于 升级成本 时，才会去升级。

升级意愿 可以通过让学院把依赖的版本考虑进健康度，事实上使用已经不维护的版本也的确是个隐患。不过 升级意愿 提高的幅度不会很大。

所以主要是要降低升级成本，就是楼顶提到的方案 #3759 (comment) 。

现在已经在内部找到愿意配合的系统，会通过 codemod + macaca 的方案尝试升级。我会去写相关的升级脚本，并由全栈使用 macaca 编写自动化 UI 测试脚本。

[benjycui]

WIP: https://github.com/ant-design/antd-codemod

这几天会陆续增加升级脚本，有兴趣的可以在本地尝试一下。

[afc163]

http://weibo.com/1503533460/EiVAk8mag?refer_flag=1001030103_

[afc163]

https://github.com/vuejs/vue-migration-helper

[benjycui]

vue-migration-helper 的实现还是太简单了，单纯的正则匹配而已，像 DatePicker[value] 这种类型变化的根本就测不出来。

思路可以参考，但是实现还是要再进一步的思考。

[benjycui]

还是用正则匹配吧，类型不好搞。。

[benjycui]

FYI

类型问题通过推动 TypeScript 可以解决，然后也有全栈提过希望使用 TypeScript，但这意味着我们需要有人深入 TypeScript，不然像 antd-codemod 之类的工具无法实现对 TypeScript 的支持。

[benjycui]

阶段性小结

升级成本主要来源于：

1. 修改已有代码
2. 回归测试

对于以上两个成本的解决方案分别是：

辅助升级工具

辅助工具已经开发完成并在真实项目中测试过，接下来主要是 bugfix 和使用体验优化。

1. antd-migration-helper
2. antd-codemod
3. antd-adapter (不建议使用)
4. antd 内置的 warning

现在的使用路径为：

1. antd-migration-helper 扫描项目代码，找出使用了废弃/移除 API 的地方，类似 ESLint
2. 根据提示修改项目代码，部分情况可以用 antd-codemod 自动修改
3. 日期类等难以升级的组件可以使用 antd-adapter 适配为 1.x 的使用方式，但不建议
4. review 并测试相关修改，没问题后 git commit，以便后面误操作时能回滚
5. 回到第一步直到没有 warning
6. 最后进入回归测试

自动化回归测试

目前还处于技术调研阶段，deadline 还没确定，有以下两套方案：

方案	优点	缺点
Jest + enzyme	配套简单	手写测试成本高
uirecorder	自动录制成本低	集成测试需要整套配套

两套方案都需要开发与 antd React 相关的配套工具。

[benjycui]

手头有 antd@1.x 的项目并且计划升级的同学，可以尝试用辅助工具升级，期间碰到的问题可以到 GitHub 提 issue，我会尽快解决。

[afc163]

来个 1.x 到 2.x 的 step by step 升级工具使用步骤。

[afc163]

@benjycui 记得把相关工具和文档写到 https://ant.design/changelog-cn#2.x-%E4%B8%8D%E5%85%BC%E5%AE%B9%E6%94%B9%E5%8A%A8 这里。升级时都以这份文档为准。

[benjycui]

Change log had been updated 0caefc8

[yangfan0095]

+1 来个 1.x 到 2.x 的 step by step 升级工具使用步骤。 看这个https://ant.design/changelog-cn#2.x-%E4%B8%8D%E5%85%BC%E5%AE%B9%E6%94%B9%E5%8A%A8

[LiXii]

从1.11.x版本升级后，使用官网上面包屑的例子出现了warning：Warning: flattenChildren(...): Encountered two children with the same key, .$. Child keys must be unique; when two children share a key, only the first child will be used.

[benjycui]

@LiXii 麻烦另开 issue，并提供重现的在线 demo，谢谢。

[lock]

This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.