tsx 的老项目代码两三万行 ; 整体运行稳定 就是速度稍慢点 , 还有一些设计问题不太灵活 想整体迁移到 vite 顺便改下结构
1
wu67 21 小时 3 分钟前
没记错的话, umi 是用的 webpack ? 所以本质上你的问题只是 webpack 迁移 vite.
考虑一下代码迁移的工作量和冷启动、热更新之间的权衡再决定升不升咯. 有个问题是 ssr, 单纯的 vite 你想做 ssr 还不是开箱即用的, 如果你们项目本身有 ssr, 那你可以还得考虑直接转其他搭配 vite 的 ssr 开发脚手架、或者 spa+puppeteer 实现 ssr 还有个问题是, react 整体环境在 vite 在运行良好, 但是对应的 typescript tsc vite 之间的小版本破坏性升级会有特定问题, 如果你们 react 现在还 不是 18.3, 那可能会付出更多的迁移成本. |
2
skallz 20 小时 32 分钟前
webpack 到 vite 有大坑,webpack 是做了很多包管理的兼容,另外以前有些用 webpack 打包的库没法直接用于 vite ,如果有提供 cdn 方式加载的库还好,有些库都实在不知道怎么做兼容,还得改源码,建议先用微前端,把旧模块一点点独立到新的 vite 项目中,不要直接把整个项目迁移,不然很容易出现延期,上不去下不来迁移进度卡死了
|
3
ltaoo1o 20 小时 8 分钟前
我记得 umi 老版本不支持 vite ,新版本 4 开始就支持了吧,所以建议迁移到新版本。
我之前也折腾过 https://zhuanlan.zhihu.com/p/399998544 ,非常麻烦,看了下时间都是 21 年了 |
4
aikilan 18 小时 17 分钟前
正好之前搞过公司内部的老项目 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 的情况下你根本就兼顾不到。 |
5
UmbraCi 13 小时 39 分钟前
@aikilan 所以总结下来,迁移成本大,边界情况多,需要非常了解 webpack 和 vite 的原理,且就算迁移完成,也是需要 dev 模式用 vite ,生产环境用 webpack 。导致生产和开发打包结果不同,上线也是问题。
|
6
ltaoo1o 12 小时 18 分钟前
@UmbraCi vite 本身开发时 esbuild ,打包 rollup ,生产和开发打包就是不同,它就是想提高本地开发效率。
再说生产也是先上测试,再到正式,不存在本地开发完直接上线上,所以这个点不算问题。 |
7
Akuta 2 小时 14 分钟前
如果迁移到 vite 不好迁移可以试试迁移到 rsbuild ,这个速度也快,相对 vite 来说比较好迁 https://rsbuild.dev/zh/guide/migration/webpack
|