公司目前有一老旧的前端项目( 5 年前开发)
采用的是 webpack2 + vue2 构建的,而且还是个多页应用(历史原因 不知道为什么,其实是一个平台项目,一个团队维护)
每个 pages 都是一个 spa,导致 build 会全量 build,随着几年的埋坑和堆屎。项目越来越大。
预计有 45 个 pages 目录,每个目录下有 10 个路由页面。
现在每次更改项目 热更新 都要几十秒才生效,构建不用说要 15 分钟左右(相当于 45 个项目 build )
我的想法:
1. 升级构建工具
2. 分析 build 慢的原因(webpack 分析工具),逐步解决,抽离 dll 什么的。
3. 按照目录结构(45 个 pages),一个一个目录优化代码,去掉无效的引用,冗余代码等等……
4. 改成 dev 和 build 都只启动和编译修改的 pages 。
其中关于 4,我有点尴尬。因为这些 pages 内部的组件有都交叉引用的。在不重构的方式下,我修改一个组件。不知道哪些 pages 引用了。。。这样重新 build 不知道 build 哪些 pages 。。。
还有个想法是,改成 spa,一个目录一个目录的慢慢整理,就是相当于重构了。时间成本比较大。
不知道我的思路是否正确。特来请教前端大佬们~~~~感谢~~~~
打算搞成 kpi 项目。如果大佬们的意见采纳,最后拿到奖金了,绝对来发红包。。。\(^o^)/~
---
补充:前后端分离项目。想搞成 spa 的原因是我们的用户访问量并不是很大(日均 2000 ip ),体验想搞好点。
采用的是 webpack2 + vue2 构建的,而且还是个多页应用(历史原因 不知道为什么,其实是一个平台项目,一个团队维护)
每个 pages 都是一个 spa,导致 build 会全量 build,随着几年的埋坑和堆屎。项目越来越大。
预计有 45 个 pages 目录,每个目录下有 10 个路由页面。
现在每次更改项目 热更新 都要几十秒才生效,构建不用说要 15 分钟左右(相当于 45 个项目 build )
我的想法:
1. 升级构建工具
2. 分析 build 慢的原因(webpack 分析工具),逐步解决,抽离 dll 什么的。
3. 按照目录结构(45 个 pages),一个一个目录优化代码,去掉无效的引用,冗余代码等等……
4. 改成 dev 和 build 都只启动和编译修改的 pages 。
其中关于 4,我有点尴尬。因为这些 pages 内部的组件有都交叉引用的。在不重构的方式下,我修改一个组件。不知道哪些 pages 引用了。。。这样重新 build 不知道 build 哪些 pages 。。。
还有个想法是,改成 spa,一个目录一个目录的慢慢整理,就是相当于重构了。时间成本比较大。
不知道我的思路是否正确。特来请教前端大佬们~~~~感谢~~~~
打算搞成 kpi 项目。如果大佬们的意见采纳,最后拿到奖金了,绝对来发红包。。。\(^o^)/~
---
补充:前后端分离项目。想搞成 spa 的原因是我们的用户访问量并不是很大(日均 2000 ip ),体验想搞好点。
