为何我最终选择放弃升级webpack4?

朱佳伟
原创 2872       2018-04-25  
webpack是当前最火的一款前端工具,它能处理包括CommonJS,AMD,ESM等各种模块与包括CSS,图片,文件等几乎各种前端所需的资源,并将其打包为各种资源模块。虽然webpack的本质是模块分析加载工具,但是丰富的插件系统也赋予了其前端构建的能力,可以替代grunt/gulp,提供诸如代码压缩混淆,图片转base64,具备热更新功能的开发服务器等功能。Light团队内的前端工程也或多或少地采用了webpack的技术,但在我们众多的前端项目还在使用webpack2时,webpack却已经迎来了v4版本,我们跳过v3,来看看最新的webpack有哪些重大变化与功能特性。

重大变化

不再支持Node.js 4。
webpack配置文件中新增mode配置项,开发者可以选择使用none, development或production,默认为production。在development模式下,会有更加完善的报错信息,提供调试工具及更快的增量编译速度。production模式下,开启了各类代码打包优化与模块作用域提升,使得bundle尺寸更小,运行更快。看到这,我流出了激动的泪水,我们再也不需要通过判断process.env.NODE_ENV来确定运行环境并决定是否添加各类插件了,如今只要简单地设置mode值,遵循webpack默认设置,就能轻松上手了。
import总是返回一个对象,CommonJS模块会封装在default属性中。所以引用CommonJS的代码将修改为import('xxx').default。
NoEmitOnErrorsPlugin,ModuleConcatenationPlugin,NamedModulesPlugin,CommonsChunkPlugin等插件已经默认集成在devlopment或production环境中,不再需要单独配置。
支持直接importJSON,在不需要json-loader。

性能升级?

在冗长的功能特性列表中,我的目光聚焦在了Performance这一项上,webpack4为我们带来了更多性能上的提升,包括了压缩代码时默认开启优化策略,编译时多处性能提升,尤其是增量编译速度将更快。看到这,我已经跃跃欲试了,毕竟在日常的开发过程中,我们已经感受到了日渐庞大的前端工程对webpack性能造成的压力,很多同事可能都养成了先输入npm run watch,泡一杯杯咖啡再回来继续开发的习惯了。既然如此,我们心动不如行动,马上来测试下webpack4的速度如何。

工程简介

我这里选择 lighting UI工程来进行webpack升级测试。lighting UI工程是一个基于weex-ui不断拓展完善的UI库工程,包含了约60个左右的UI组件源码(.vue文件)及示例页面。


在工程的webpack配置文件中,导出了两个webpack配置,其中一个通过vue-loader与babel-loader生成web环境中使用的js文件,另一个配置通过weex-vue-loader与babel-loader生成在native环境中使用的js文件。

版本升级

接下来我们修改package.json中的webpack版本,从^2.7.0变为^4.5.0,执行npm install重新安装依赖后再执行npm run build。

首先跳出了安装webpack-cli的提示,webpack4中webpack命令行被分离到独立的一个npm包中,我们输入yes继续。
第一次编译失败,错误来自于CopyWebpackPlugin,我们首先想到的是升级插件版本,将插件升级到最新版本后重新编译,我们又得到了来自vue-loader与weex-vue-loader的报错,同样,我们也将vue-loader从^12.2.2升到最新版本14.2.2。再次尝试,来自vue-loader的错误也消失了。
然而将weex-vue-loader更新到最新版本后,编译时错误也依然存在,显然weex-vue-loader更新过慢,已经不兼容webpack4,这个时候升级之路似乎陷入了僵局。

兼容错误


不得已,我们只能根据编译时错误来排查weex-vue-loader源码中不兼容的代码。 
根据错误,我们能够简单地得出结论,在loader的上下文中已经不存在options这个属性,所以才出现了当前错误,同时我们也在webpack4的Removed features中得到了验证。

那么,我们如何去拿到这个神秘的options呢,通过输出loader的上下文,我们发现在this._compiler中存在一个options属性,我们大胆猜测this._compiler.options可以替代原有的options,我们的猜测看起来没有问题,在修改了相关代码之后,编译终于成功了。这个时候可以完成我们最初的心愿——测试webpack4编译速度。

对比结果

在平时工作过程中,我们更加关注的是在工程在开发模式下的编译速度,于是我们先修改原有的webpack配置文件,将devtool的值从source-map设置为eval,这样我们能以较快的速度得到map文件而不影响调试。而在webpack4的配置文件中,我们同样修改devtool的值为eval,并加上mode值为development的配置项。 


一轮测试下来,结果却让人大跌眼睛,单独编译[name].web.js时,两者时间相差无几;而单独编译[name].native.js时,webpack4的时间远远大于webpack2的时间,同时也出现了webpack2编译时不存在的语法警告。到这里,我似乎恍然大悟,正如在升级公告中写到的那样,webpack4在开发阶段默认开启了语法检查与devtool甚至更多我们无法配置的优化项,一切只为了在更好的开发体验与更快的编译速度之间找到平衡点。

总结

折腾到这,我们的这次测试也宣告失败,但这也并非是毫无意义的一次探索。 
我们在升级webpack4时体会到了mode配置项的引入对初始化工程配置带来了极大的便利,虽然遇到了weex-vue-loader不兼容的问题,使得该工程无法升至webpack4,但在其他工程中我们可以有取舍地去选择是否升级webpack4,毕竟也有相当多的loader与plugin已经支持最新的webpack了。最后希望webpack4的生态尽快完善,给开发者带来更好的体验!

恒生技术之眼原创文章,未经授权禁止转载。详情见转载须知

联系我们

恒 生 技 术 之 眼