各位大佬和巨佬们 react 的 umi.js 前端项目迁移 vite 成本高不高 ?

[ixixi]

tsx 的老项目代码两三万行 ; 整体运行稳定 就是速度稍慢点 , 还有一些设计问题不太灵活 想整体迁移到 vite 顺便改下结构

[wu67]

没记错的话, umi 是用的 webpack ? 所以本质上你的问题只是 webpack 迁移 vite.

考虑一下代码迁移的工作量和冷启动、热更新之间的权衡再决定升不升咯.

有个问题是 ssr, 单纯的 vite 你想做 ssr 还不是开箱即用的, 如果你们项目本身有 ssr, 那你可以还得考虑直接转其他搭配 vite 的 ssr 开发脚手架、或者 spa+puppeteer 实现 ssr

还有个问题是, react 整体环境在 vite 在运行良好, 但是对应的 typescript tsc vite 之间的小版本破坏性升级会有特定问题, 如果你们 react 现在还 不是 18.3, 那可能会付出更多的迁移成本.

[skallz]

webpack 到 vite 有大坑，webpack 是做了很多包管理的兼容，另外以前有些用 webpack 打包的库没法直接用于 vite ，如果有提供 cdn 方式加载的库还好，有些库都实在不知道怎么做兼容，还得改源码，建议先用微前端，把旧模块一点点独立到新的 vite 项目中，不要直接把整个项目迁移，不然很容易出现延期，上不去下不来迁移进度卡死了

[ltaoo1o]

我记得 umi 老版本不支持 vite ，新版本 4 开始就支持了吧，所以建议迁移到新版本。

我之前也折腾过 https://zhuanlan.zhihu.com/p/399998544 ，非常麻烦，看了下时间都是 21 年了

[aikilan]

正好之前搞过公司内部的老项目 umi 支持 vite 开发，简单来说要处理：
1：路由（路由重新生成，路由参数注入，路由跳转方式兼容）
2：样式文件需要处理为 xxx.module.xxx ，不要试图用插件去处理 scope 样式，该踩的坑都踩过了，还是改名更快，当然，改名的同时要注意把全局样式剥离成单独的文件，当时单独写了个 node 脚本检查样式文件是否正确引用。
3：一些静态资源的处理，比如 svg 之类的
4：环境变量注入的方式变动，比如 vite 使用 define 来注入全局变量
5：热更的处理，webpack 对于循环依赖、tsx export 类型、常量都是支持热更的（虽然也不是很热），在 vite 中，由于 react-refresh 的限制，tsx 如果不是一个纯纯的 export default Component ，那么你就要 hack 热更这部分了。
。。。做完之后，你最好还是只用在开发，别直接上生产，这涉及到 vite 开发与构建本身产物就有差异，且低版本需要用 legacy 单独处理，这中间再来一道已有的 webpack 的复杂产物，可想而知在一些 corner case 的情况下你根本就兼顾不到。

[UmbraCi]

@aikilan 所以总结下来，迁移成本大，边界情况多，需要非常了解 webpack 和 vite 的原理，且就算迁移完成，也是需要 dev 模式用 vite ，生产环境用 webpack 。导致生产和开发打包结果不同，上线也是问题。

[ltaoo1o]

@UmbraCi vite 本身开发时 esbuild ，打包 rollup ，生产和开发打包就是不同，它就是想提高本地开发效率。

再说生产也是先上测试，再到正式，不存在本地开发完直接上线上，所以这个点不算问题。