写在前面: 这文章写于15年底,后来16年才放到segmentfault上来,看到陆续仍是有浏览量甚至收藏,以避免形成误导仍是在文章前头稍稍提醒一下.
当时观点放到今天不免有些打脸,就目前来讲webpack已经彻底占据主流位置,连我本身的项目都不多会在开发阶段用glup了.但我依然以为webpack与glup二者职能不一样,例如把一些相似测试任务
,上线部署
之类的事交给gulp这类构建工具是很天然而然的事.webpack依然是打包工具,而打包,只是构建的其中一环而已.
我已经不是第一次看到这相似的话语,为数很多的人都以为webpack是目前前端工程化完整性解决方案,打出了终于再也不用纠结使用grunt或是gulp了的旗号,只要使用webpack就足够了javascript
而事实果然如此?css
首先看看webpack官网给出的解析html
webpack is a module bundler.
简单来讲,官方对webpack的定位是模块打包器,相比于gulp或是grunt,webpack的竞争对手应该是browserify之流前端
就连webpack官方也给出了webpack with gulp的一些说明java
虽然webpack的确能够代替gulp的一些功能
可是很是明显webpack和gulp/grunt就不是一个职能
的工具
因此说取代
还言过其实(以前个人一个提问)react
那么问题来了webpack
为何是gulp
而不grunt
?
由于我用的是gulp - -!
要构建这样一个工做流,首先要理清几个问题git
就如前面所说,webpack只是一个模块打包器,因此,交予webpack处理的应该已经是通过各类lint检查,各类编译处理的代码
而各类检查,各类预处理就应该交给gulp之流了
最后压缩代码应该要交给webpack最后打包时再去执行es6
以前一直没有注意这个问题
看看gulp的基本使用github
gulp.src('client/templates/*.jade') .pipe(jade()) .pipe(minify()) .pipe(gulp.dest('build/minified_templates'));
对于开发中gulp会使用watcher
实时检查文件是否更新,检查到有更新则立刻跑相应的构建任务,可是有上面的代码能够看出,gulp每次都只能经过通配符匹配大量的文件,而不能就单单获取修改过的文件,这种状况在大型项目中每次构建都会花很多时间,更别论要在构建任务以后再加一个webpack的打包任务
不过所幸上网找到一个gulp-changed的插件,实在棒!
以前开发时live reload都是交给gulp的,而如今gulp的构建任务并非在任务链的最后端,由gulp来实现显然再也不合适
基于上面的思考,我作了个尝试项目
作些简单的说明,上面的项目只有简单的几个构建任务
js
gulp.task('js', function() { return gulp.src('src/**/*.js') .pipe($.changed('build')) // .pipe($.babel({ // presets: ['es2015', 'react'] // })) .pipe($.eslint({config: 'eslint.config.json'})) .pipe($.eslint.format()) .pipe(gulp.dest('build')); });
只简单的用eslint检测一下语法而已,而注释的部分,是使用babel把es6的代码转化成es5的代码,可是这部分应该是由webpack在最后打包阶段处理,因此去掉了
css
gulp.task('css', function() { return sass('src/**/*.scss') .pipe($.changed('build')) .on('error', sass.logError) .pipe($.replace('@@FILEURL', fileUrl)) .pipe(gulp.dest('build')); });
就是把scss转化成css,并替换掉css文件中的占位符(能够根据需求加上自动合并雪碧图或者postcss处理等等)
这里要说明一下在这个示例项目中其实并无实际编写任何css或scss,由于项目中的todo应用实际是从redux todo直接拷贝的 = =!
html
gulp.task('html', function() { return gulp.src('src/**/*.html') .pipe($.changed('build')) .pipe($.replace('@@FILEURL'), fileUrl) .pipe(gulp.dest('build')); });
就没什么好说的,就是作了一下占位符替换而已
若是是使用其余模板引擎就能够在这里进行编译
而live reload应该怎么作呢?
参考了一下react-transform-boilerplate和redux todo(其实仍是直接拷贝的= =)
gulp.task('default', ['clean', 'js', 'css', 'html', 'watch'], function() { var app = require('./devServer'); var port = 3000; app.listen(port, function(error) { if (error) { console.error(error) } else { console.info("==> ? Listening on port %s. Open up http://localhost:%s/ in your browser.", port, port) } }); });
就是再把全部任务跑一遍后启动实现live reload的devServer
修改文件时,gulp就会从src
->build
进行构建,而webpack则是检测着build文件夹是否有更新来进行增量编译,同时实现live reload
至此,已经把脑中想法基本实现了出来(其实并无,bug多多的说)
再来讲说实践事后的想法
webpack果然是业界杀鸡用牛刀的最佳代言人
好吧,多是我接触webpack不久
在如此小的应用上,使用webpack真是一点都体会不出它的好处
(惟一一点可能就是es6的import语法而已,不过要使用import仍是react或redux等等库的坑)
在大型项目使用可有成功案例,但愿你们不吝指教一下^ ^~
另一点,我还看过几篇比较gulp和webpack的博文(国内外都有)
大意其实都差很少,就是说,若是用gulp,你要写多不少代码,你将会有很是多的开发依赖balabala....
而用webpack,你就能够经过少许的代码解决这些问题等等等等的,
且不论代码多少
的问题,这点我并无实践过
可是再一次代表个人见解
webpack和gulp/grunt就不是一个职能
的工具,谈何取代?
至于代码多少的问题
有没有想过,代码少
就真的必定好
吗?
我认为,gulp/grunt
或是browserify/webpack
等等工具的面世,其实都是为了解决前端的工程化问题
在工程化问题
面前,难道追求的真的是write less, do more
吗?
举个例子,各类MV**
的设计模式,真的有让你们少写
不少代码吗?起码我并不以为有那么一回事
我认为,付出适当的代价,组合使用各类工具,使用合适的工做流,才能真正起到管理前端工程的做用
至于何为适当
,何为合适
,依然须要探索