webpack-ng-dll-plugin
用处
应用
- 首先依据集体相熟水平抉择
@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
可能解锁的技术
失常状况下,哪怕是动静加载的路由,也是与我的项目一起打包,只不过是打包为两个文件
主体我的项目先打包,而后再独自开发懒加载路由模块
尽管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左右