blog
blog copied to clipboard
sorrycc
Umi 3.1，支持 mpa，编译大幅提速，两种 node_modules 编译方式，优化 defineConfig 的 TypeScript 体验
不寒暄了，经过一周的开发，我们增加和改进了以下功能。
支持 mpa
通过一个自定义的 Umi 渲染器 renderer-mpa 实现 mpa 的支持，复用现有的路由配置和绝大部分能力，每个页面需要有一个 React 组件出口。不是传统意义上的 mpa，但 React 应用的场景下够用。
mpa 由于不会引入 react-router 和 history，一个简单的 mpa 应用尺寸可以控制地很小。试了下 mpa + preact + 禁用 polyfill 的组合，产物只有 18 Kb（gzipped）。
构成如下，
详见 mpa 配置。
编译提速
把 Umi 3 增加的时间降回来，而且降地更多一些。
分别试了下最简项目和 antdpro 项目，最简项目无缓存编译从 7s 到 2s，antdpro 初始项目无缓存编译从 48s 到 27s。
背后我们做了几件事，
- 允许用户配置不编译 node_modules 依赖（视依赖不同可能减少 30% - 60%）
- 把处理热更新和错误渲染的 webpack-hot-dev-client 提前打包（减少 2-3 秒）
- 允许用户配置在 dev 时 external react、react-dom 等（减少 2-3 秒）
- 允许用户一键切换到 preact（减少 2-3 秒）
- 允许用户配置在 dev 时不开启补丁（减少 2-3 秒）
两种 node_modules 编译方式
node_modules 到底走不走 babel 编译？是个很纠结的问题。Umi 3 时参考 create-react-app 的实践引入了全量编译，但引发了不少编译速度和 OOM 问题。
所以，我们把 Umi 2 时不编译 node_modules 的方式也加了回来，供大家选择。
两种方式，
- 全量编译，但不编译某些依赖
- 不编译，但只编译某些依赖，es5-imcompatible-versions 下声明过的始终编译
优化 defineConfig 的 TypeScript 体验，支持插件配置
之前的 defineConfig 只支持内置的配置项，现在通过把 joi 的 schema 定义自动转为 ts 定义的方式，支持了插件的配置项的 TS 提示和校验。
其他
- 依赖升级，Babel 升级到 7.9.5
- 脚手架在 postinstall 里执行 umi generate tmp，并且默认不编译 node_modules
👍 👍 👍 👍 👍 👍👍 👍 👍 👍 👍 👍👍 👍 👍 👍 👍 👍👍 👍 👍 👍 👍 👍👍 👍 👍 👍 👍 👍👍 👍 👍 👍 👍 👍👍 👍 👍 👍 👍 👍👍 👍 👍 👍 👍 👍👍 👍 👍 👍 👍 👍👍 👍 👍 👍 👍 👍👍 👍 👍 👍 👍 👍👍 👍 👍 👍 👍 👍
666
------------------ 原始邮件 ------------------ 发件人: "chencheng (云谦)"<[email protected]>; 发送时间: 2020年4月8日(星期三) 下午5:14 收件人: "sorrycc/blog"<[email protected]>; 抄送: "Subscribed"<[email protected]>; 主题: Re: [sorrycc/blog] Umi 3.1，支持 mpa，编译大幅提速，两种 node_modules 编译方式，优化 defineConfig 的 TypeScript 体验 (#93)
太 6 了，希望编译速度可以再提升
还可以从 27s 到 8s 内，今年的目标之一。
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Babel 升级是跟着 umi 自动升的，还是必须新创建的umi 项目才会使用新的版本？老的项目把 umi 升级到 3.1以后，看 @babel/core 的版本，还是 7.9.0
按这个操作--“允许用户配置不编译 node_modules 依赖（视依赖不同可能减少 30% - 60%）”
MacBook Pro (Retina, 15-inch, Mid 2015) 升级前dev 41s build 62s 升级后 dev 16s build 30s
ThinkPad T470P 升级前dev 90s build 90s 升级后 dev 25s build 33s
不是最简单项目，是带了图表库的。
前两周刚刚创建的ant design pro的项目，用了umi3.1.0后，yarn start要20+几分钟才能启动，中途没有报错误。但这速度没法开发了，删除node_modules重新yarn还是老样子，太坑了吧！提的什么速？！
3.0.14的时候yarn start几秒就好了
前两周刚刚创建的ant design pro的项目，用了umi3.1.0后，yarn start要20+几分钟才能启动，中途没有报错误。但这速度没法开发了，删除node_modules重新yarn还是老样子，太坑了吧！提的什么速？！
3.0.14的时候yarn start几秒就好了
虽然提速不是特别明显（可能也要等 ant design pro 更新吧），但也不要20+分钟，你这是什么年代的机器啊？
1、先用umi3.0.14创建了pro应用，yanr、yarn start正常，可以和后台一起开发部分功能 2、执行yarn upgrade -lastest umi升级到最新版 3、再yarn start启动前端 以上在Windows7上验证@xiaohuoni
D:\projects\mt-front>yarn start yarn run v1.22.4 $ umi dev � Starting Umi UI using [email protected]... � Umi UI mini Ready on port 3000
Starting the development server...
- Webpack █████████████████████████ building (68%) 2107/2147 modules 40 active babel-loader » node_modules\rc-progress\es\enhancer.js
就这样，大概68%左右会占去大部分时间，就这么慢。 电脑16Gb内存，I7的cpu 换回3.0.14后，yarn start还是要几分钟，不过比3.1.0还是快了不少，这真的太坑了！
@fengnex 给你一个我的测试demo吧。效果和时间在上面的评论里面有。我这边找不到win7的电脑 nextApp.zip
yarn yarn start开启时间为20秒左右
我的是win10，16G，I7CPU，三星全固态硬盘，遇到同样是启动慢的问题
截至昨天，umi有2000+（2099）个release，吓到了有没有，发布的质量应该是比发布的次数远远重要吧！
这是因为，每次都是一起发包，发一个版本，有几十次releases
@fengnex 给你一个我的测试demo吧。效果和时间在上面的评论里面有。我这边找不到win7的电脑 nextApp.zip
yarn yarn start开启时间为20秒左右
win10，8G，I5CPU，12s+，node v12.13.1
