webpack-ng-dll-plugin
- ng 版本可用的 dll 插件, 路子比拟野
用处
- 进步打包速度
- 代码复用(微前端依赖共享)
应用
- 首先依据集体相熟水平抉择
@angular-devkit/build-webpack
,@angular-builders/custom-webpack
,ngx-build-plus
第一个是官网的, 后两个是第三方的, 然而确认你有练过之前, 请不要抉择官网的 …
作者在测试的时候抉择的是@angular-builders/custom-webpack
- 先构建 dll, 倡议应用空我的项目来创立 dll, 因为目前开发中并没思考到一些简单逻辑的实现及相干第三方包的依赖关系保留(full 模式应该能够实现, 实践)
- 而后在构建时
援用
援用就是 webpack 的失常援用插件就 ok 了
尝鲜
- 上面的函数过滤了
index.html
,styles
,polyfills
,License
的输入, 并且禁用了runtimeChunk
setNgDllPlugin(
config,
{
//webpack 的 out 相干配置
output: {filename: 'dll.js',},
ngDllPluginOptions: {
// dll 的资源清单导出配置
path: path.join(__dirname, 'dist', 'manifest.json'),
name: 'TLIB',
format: true,
filter: {// 过滤模式,full 全量,auto 绝对于我的项目,manual 手动指定过滤项(须要设置 map)
mode: 'auto',
},
},
},
options
);
自定义
- 相干配置须要参考(临时没写文档, 须要查看源码)
config.plugins.push(new NgDllPlugin(option.ngDllPluginOptions));
援用
// 这里的 context 能够了解为代码 (利用代码) 绝对于哪个文件夹解析(不是打包进去的 dll.js, 如果正确援用, 你会发现把 dll.js 删掉, 也不会影响打包), 如果发现打包进去的货色没有应用这个, 应该就是这个配置错了
config.plugins.push(
new webpack.DllReferencePlugin({context: path.resolve(__dirname),
manifest: require('./dist/manifest.json'),
})
);
演示地址
- https://github.com/wszgrcy/ng-cli-plugin-demo
可能解锁的技术
- 分体式路由加载
失常状况下, 哪怕是动静加载的路由, 也是与我的项目一起打包, 只不过是打包为两个文件
主体我的项目先打包, 而后再独自开发懒加载路由模块
web-component
的使用率回升
尽管 ng 曾经实现了这个, 然而因为每次一大包, 就相当于打了一个独自我的项目, 十分宏大, 应用 dll 后则会放大到一个可怕的水平, 副作用靠近 0
目前 (可能) 存在的问题
- 资源清单输入的是全量的援用, 然而实际上, 只有
mode:'full'
时, 才等价
没批改之一次要是影响不大, 加上调试须要
- 如果生成 dll 的我的项目中有动静加载模块, 可能有未知影响
dll 在设计的时候基本没思考过动静模块之类的货色, 齐全就是只打一个大包
尽量应用空我的项目生成 dll
- auto 只代表以后生成我的项目能够达到齐全援用, 如果你批改了我的项目, 那么必须从新构建我的项目(额. 看起来比拟废物的一个模式)
其实如果我的项目代码足够多(各种品种), 批改代码是不影响的, 然而比方有些引入第一次应用, 或者 html 模板中应用了一些新的货色, 都须要从新构建
待改良
- 被动排除一部分永远无奈应用的导出
为什么 dll 比间接打包大
- 即便 dll 打包当初应用到了 ng 的 aot, 摇树等相干优化技术, 然而依然有个致命问题, 就是导出名, 默认打包时, 所有名字都会被优化(混同), 而 dll 打包就必须裸露这个名字, 当齐全裸露时, 就会呈现体积增长
目前用空我的项目生成出的 dll(包含 rxjs,router,common,core), 全量暴力是 440k(也就是说当其余包应用时这些文件都会在 dll 中查找), 选择性导出最小化启动在 216k 作用, 最终预计应该均匀在 300k 左右
- 目前应用的技术, 只能 1. 全量导出,2. 抉择可用导出, 这其实就有一个副作用存在, 全量导出时. 不仅一些不应用的依赖被导出了, 还有些外部援用的 (比方
ɵangular_packages_core_core_h
) 也被强制导出了, 从而减少了包大小
前期, 其实能够整顿一个永不导出的列表, 进行排除, 从而减小体积
- 传统打包是多个模块打包一个模块, 两头很多依赖都是属于外部依赖, 所以精简了很多代码,dll 的这种打包属于多模块, 因而每个模块都有进口, 之间的援用也是用的模块之间的援用, 所以即便最小化 dll 也会比打包的多 40k 左右