持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第1天，点击查看活动详情

可以浏览到哪些

split uni-app中的h5框架代码，/[\/]node_dodules[\/]@dcloudio[\/]/
uni-app 大概是怎么构建H5的

为什么选择uni-app

如当前章节所及，主要目标是解决业务快速迭代，而非研讨跨端方案的优良
uni-app， taro， chameleon的抉择，公司因素占大比例（vue）
直接写H5不行吗？为什么非得用这么重&不灵活的

涉及投放场景：微信小程序、独立H5、字节小程序

综上，uni-app属于贴合公司的最优业务解决方案！既然享受了快速迭代多端的便捷，同时肯定要接收其带来的不灵活。

为什么会有此次构建的分析与拆包

使用过webapck4/5 的同学肯定会晓得哪些code会被bundle到 chunk-vendor.js 文件，意味着不仅存在框架性代码，也存在一定的业务代码。
监控平台监测到chunk-vendor.js路径下，发生xxxx错误，很难判定是否属于RD编码错误（可以通过map文件进行定位，if has）
平时大家都会将框架性质的模块单独提取chunk / 或利用独立的cdn加速之类的操作

想当然的第一步

利用vue-cli 创建的项目，非常easy的就可以将框架代码单独提取 chunk 或者替换为cdn链接(比如 Vue、ElementUI）（todo: 日常webapck提取）
但是吃了闭门羹，按照step1的操作，直接丢失了uni-app自有的周期（onLoad、onShow、onHide 等等）。

上结论

为什么splitChunks的不会被加载呢，因为78行的chunks对filename注入的脚本进行了指定，对应构建的hash值文件名就会打进index.html中。so 那个hahahRonan是我自定义的包名。酱紫的话就可以将splitChunks提取的包名(不含hash)写到这里了

且看

uni-app 自定义了vue-cli-plugin-uni, 注册了uni-build的command，最终通过build()运行webpack构建

运行webpack构建，肯定离不来webpack config，看到64-78行的时候，就能恍然大悟了，webpack的常规分包策略为什么不好使，看到here就了然了。

如何定位第一刀

看图说话，chunk-vendors.js中最最最最最鲜艳的就是node_modules/@dcloudio了，大概这样就能提取@dcloudio下的所有了

下图可以看出来，h5构建时候，最终使用的是main: dist/index.umd.min.js,直接指向了构建后的文件

我大概是这样子做的

如何进行第二刀（将分离的包自动注入到侯建后的index.html中）

愚昧无知的我，选择正面冲锋，为了Team fighting，自己改源码能行，team 成员或者部署平台就尴尬了

来看看效果先

#	##
拆包前
拆包后

监控的效果就不贴了

发现彩蛋

修改别人的源码往往有这几个方式：

1.  直接在项目的node_modules下找到插件的源码直接修改；
1.  -   **优点**：简单直接、快速见效
    -   **缺点**：不能持久化，一旦重新安装就失效；不方便团队成员使用修改后的代码
1.  去github上fork代码到自己的仓库进行修改，并将自己修改过后的代码发布到npm上使用；
1.  -   **优点**：团队成员都可以使用到这份修改的代码
    -   **缺点**：麻烦、十分麻烦

显而易见，上面这两种方法既不优雅，也不可靠。作为程序员的我们岂能被这事儿给难住，开源社区早已给我们准备好了解决方案：**patch-package**[1]

原文：如何做到修改了 node_module 中的包，却不受重新安装的影响: mp.weixin.qq.com/s/IcCQ9Lq96…

概要：通过patch-package包，可以不用硬钢修改源码打各种补丁，可以不用fork源码发布npm；包这里：www.npmjs.com/package/pat…

后续

单独提取，脱离webpack，因为每次构建都会产生hash文件名，cdn 以及 cache等不能得到很好的利用
参考 vue-cli 生产的webpack策略应用到uni-app的H5构建中（个人理解 vue-cli内置的webpack策略目前是最优解的经典）

if 你已经有了最佳实践，期待能够分享到我，如有纰漏，欢迎交流探讨！硬钢肯定是你对！！

uni-app H5 分离uni-app框架代码（减小chunk-vendor体积、如何构建H5端分析）