继续上一篇"前端打包优化(一) "
现在开发基本都是使用npm或者yarns进行依赖管理,随便引入几个依赖就会使得最终打包的结构臃肿,再加上开发者可能对依赖的包并没有特别统一管理,需要什么就引入什么,不会去关心互相之间的关系。
上图仅仅是说明node_modules管理的时候出现的包的量一个图,可以说是非常的形象。图片来自文章What’s really wrong with node_modules and why this is your fault,文章推荐一看
注:npm包开发者应该保证包里面仅只有需要的代码,比如测试等等的资源最好都忽略掉,这样也可以省去不少开支,细节后续会整理一篇新的文章。
多人开发常会遇到使用三方库,部分人使用deep-extend,但是后面可能又有人用lodash,这样一来一回,会出现同样功能的包会引用多个的问题。对于这个情况不会导致bug,但是会造成node_modules增多且package.json依赖混乱,当然代码大小也会有相应的损失。
解决方式
查看仓库的package.json,比如
{
"deep-extend": "^0.4.1",
"lodash.clonedeep": "^4.5.0",
}
如上俩个库都是想做深拷贝,可以选择只使用其一即可,推荐
大部分情况这样仅只会加重代码的体积等,但是在少数的场景下,比如使用了前端组件库;
举个例子,项目中依赖了俩组件A和B,A依赖了某UI库C的1.0.0的input,而B依赖了C中的2.0.0的input,最终页面上会同时存在俩版本的input,这里存在一个隐患(如果俩组件有Dom节点结构调整发生样式变化,这个时候无论是使用1.0.0或者是2.0.0的样式其实都不合适),所以这个问题也需要多关注的,特别是前端的UI库,最好习惯性的排查下较为好。必须最好做下
解决方式
打开chrome调试工具,查看node_modules,对于UI的库,仔细翻翻,不能有多版本的库,对于其他库则可以佛系排查;如果发现某个库A出现了多次,可以使用npm ls A来查看是在什么地方多次引用到了,然后再定位到具体细节的包查看
使用webpack的使用BundleAnalyzerPlugin或者是用自带的功能输出json,进行分析,排查为什么最后输出的资源这么大的原因
比较适合那些整站的开发,将各个页面公用的资源抽离出来,这样在页面的访问过程中浏览器可以很好的将这些通用资源缓存,类似使用dll存在本地工程中,还可以使得打包加速,下面以dll为例
做法
注意点
官方也是推荐使用它来代替babel-preset-2015,根据业务所需要适配的浏览器去选择合适的,否则使用多余的转码会是的代码转码后更大,同时对于browsers的设置,也可以跟postCss进行统一
一些组件库或者是lodash
import { isEmpty } from 'lodash';import isEmpty from 'lodash/isEmpty';
所产生的结果是不一样的。除非使用一个转码的工具来支持;vscode用户建议装一个Import Cost
升级到webpack3,有tree shaking、Scope Hoisting都对代码有着不错的优化