在gulp上体验webpack的简便

Posted 2021-04-08 HTML5特训营

在2016年的年底不妨来回顾一下今年的前端行业发展吧，今年的前端行业就像是一位刚刚选秀了后宫佳丽无数的皇帝一般左拥右抱，无数新规得宠的背后当然也是有些“人老珠黄”再无圣宠。

      2014年新晋贵人grunt最近似乎并不吃香，在gulp之后又加入了webpac这个对手，在前端开发自动化的领域愣是形成了三足鼎立的态势，虽然2016年的网民意更佳倾向于webpack，但“忠心旧主”的程序员们是不缺的，目前grunt、gulp的追随者依旧不在少数——看github上一些开源代码包含grunt、gulp的命令文件就知道了。

      当然最后还是得说一下个人不选择webpack的原因，百度一下webpack以及gulp的区别，发现gulp是一款透明度高、技术要求高的工具，而webpack是一款提供：黑盒的，苹果式的服务工具，不需要了解底层只要做好配置就可以了。

      作为一个有底层强迫症的人来说，webpack实在是太不透明了，一款自己每天在用的工具自己居然不了解原理，细思极恐。gulp可以基于nodejs直接编程开发，也就是说——为自定义工具提供了极高的可能，同时在前端自动化过程中就算是新贵webpack也需要gulp进行辅助才能实现文件的一键上线，那么为什么不甩开webpack自己来一个呢？

说干就干，先上框架图：

东西名叫：gbuilder，包含四个主要功能：javascript的预编译、压缩；css的预编译、压缩；html模板的预预编译；一键部署等任务的开发（task）。

      这种类型的项目实现代码中程序员最容易想到的可能是if或者switch，因为项目需要支持普通js、es6、react、vue（typescript的前端发展趋势个人实在是不看好，难不成要把目前的前端生态全部改写成d.ts吗？）针对这种大量的if或者switch判断（此处还没有算上css部分的less、scss、stylus的条件判断），而且在未来的发展中指不定那天又出来一个新规得宠的css或者js的预编译器，到时候再加点if、switch之类的就尴尬了，而且一个页面那么多if、switch的代码绝对会让代码的开发维护进入可怕的噩梦。

      这里我们采用设计模式中的策略模式来解决这个问题，四大任务集：javascript、css、tmpl、task每个任务集都是各种策略的集合，利用javascript先天弱类型以及json表达式的优势来实现功能的添加。

      每次增加一种预处理器只需要在processLoader中增加对应策略的import，每种策略都有一个“策略名称”该名与gbuilder.config.js中所配置的loader属性相互对应，程序会从loader属性中查找对应的loader字符串作为策略名称加载对应的策略进行预编译。

      目前版本只实现了javascript的es5、es6、reactjs部分的loader与watcher任务，其他部分待开发，源代码遵守BSD开源协议，欢迎所有人Fork并提交自己的processLoader策略。

      简单的使用来自复杂的技术、复杂的技术来自想要一探究竟的开发者。重复造轮子又何妨，技术就是在一次次的模仿中学习起来的，真正实用的东西并不是最流行的，而是最合适的。

【请扫描二维码，获取更多文章】