RsPack是什么
介绍 - Rspack 本次迁移的版本是0.2.11
为什么选择了RsPack
我们现有的项目有几十万行的代码，数百个页面。之前是webpack 3，每次流水线编译时长高达600s。 后来迁移到webpack5，并开启了持久化缓存优化，chunk优化，将编译时间缩短到了200s左右，如果持久化缓存命中的话，则能缩短到60s左右。
这已经是非常好的效果了，但是依然存在几个问题：
- 缓存命中是不稳定的，这是由于公司流水线的设置问题。
- 持久化缓存只能在测试和ST环境使用。
- 开发人员使用频率最高的冷启动和热更新，依然有点慢。冷启动达到了20S，热更新在部分页面达到10S左右。
这些都是可以忍受的问题，但是碰巧最近一次需求优化，涉及范围非常广。因此衡量了测试范围和开发时长以及接入成和回滚成本之后，我决定把webpack5 迁移到RsPack上。
- RsPack与Webpack5的迁移基本上是无缝的，配置差异很小。
- 我们的项目主要是页面多，但是使用的都是常规的React技术栈，几乎没有第三方的插件。这样的话，不管是接入还是回滚到Webpack，成本都不高。
- RsPack本身是基于SWC的，SWC已经有很久的实践了，RsPack自身也在字节内部使用了一段时间，因此完成度和稳定性还是比较高的。在git上看，issue解决的速度也很快，有问题也不是很怕。
- 由于本身此次需求就涉及到了所有的一级页面，因此测试的回归面就很广。利用这次机会，正好做迁移。
迁移成本和收益
- 从webpack迁移到rspack本身只花了1个多小时的时间。初次启动效果很好。
- 冷启动缩短到了7S左右，热更新保持在1s以内。体验提升很高。
- rspack尚未支持持久化缓存，因此每次部署都是全量编译，但是很稳定的能达到30S左右。 效果非常好。
爬坑
在后续的测试中，也发现了一些小问题。
- 自定义插件时，发现chunk的访问有问题。推测是因为rspack开启的多线程异步拼接chunk，在拼接时有一些阻塞或者死循环，导致在访问时，chunk迟迟无法读取到。这个最终使用了流水线插件来做替代方案。问题已经提交给Rspack，尚未解决。
- RsPack对react的编译默认是非classic的。意外的发现某个第三方插件，居然是根据编译结果中是否包含creatElement关键字来判断的，非classic模式的编译是将JSX编译成了_jsx，导致第三方插件使用异常。
- 对于CSS编译，如果使用 url:("data/base64.....")这种方式来加载图片或者svg，会报错。RsPack会将其编译为 url:(data/base64.....)，去掉了引号导致语法报错。目前这个问题官方说新版已修复。但由于我去掉了这部分代码，现在没验证。
- 生产环境编译时，默认的minizer是true.发现会把CSS中的content压缩，导致概率出现乱码。将minizer置为false后正常。
经验
- 自定义插件这块的问题比较致命，因此在迁移前，首先要判断自己的插件能否正常使用。自定义插件的语法，本身与 webpack是相同的，理论上所有的webpack插件时可以直接在rspack中使用的。官方提供了一些兼容插件，官方未明确说兼容的，还是要自己测试一下比较好。
- 其他的问题并不致命，换一种实现方式即可。
结论
目前来看，Rspack带来的提升是有的。 只是对比Webpack5，相差没有那么大。 非常不错，期待Rspack更进一步的发展。
