webpack和gulp的关系是什么？

Question

webpack和gulp的关系是什么？
怎么搭配使用？
假如用了gulp就不必再用webpack了么？有个插件gulp-webpack，拿来干啥的？

Answer 1

这个问题提的很好, 其实gulp 可以理解为node 环境下的批处理命令, 就像ruby 环境下的rake. 就是说gulp 通过丰富的插件可以做任何事情.

那webpack又是什么呢, webpack可以理解为专门针对前端代码打包的集成方案, gulp可以做到webpack做的, 但webpack做不到gulp能做的. webpack只是针对前端代码的, 例如前端代码的合并,压缩, 把ES6代码转成ES3代码, sass转css等.

gulp 还可以对node 的服务器端的程序做处理,例如批量生成文件, 运行启动服务等等.

至于选择哪个一般看个人喜好和项目要求, 一般react的项目用webpack比较多,其他的项目用gulp比较多

Answer 2

webpack是用来打包的，而且打包这件事干的比gulp好的多，gulp是一个任务管理工具，理论上可以做任何事，当然包括打包。

如果你只需要打包，选webpack，如果你还想做别的比如图片合并压缩，你可以用gulp结合webpack，让webpack负责打包部分，其他工作让gulp来做。

但webpack并不一定适合所有项目，参见另一篇分析：Webpack是答案吗？

Answer 3

谈及 task runner，一般我们需要操心两件事，源码管理和任务组织，通过它们我们来定义依赖关系。

gulp的核心源码管理方式在于管理文件夹，类似gulp.src('path/to/src/**/*.js')的定义天然适合已经组织好的文件夹结构。它有弱项，它的核心glob语法不能抽取文件夹路径中的模式，但这个问题可以自己写补丁来完成，毕竟任务过程是自己写的。

而gulp的任务划分与排序是需要我们手工做的，一般而言，对于一个已经有成型文件夹管理模式的项目，切换到gulp会相对简单。但对于大项目，持续性的手工管理将越来越麻烦。

webpack对于你的源码管理而言，它需要你在代码中声明依赖，且将js作为项目入口。这样的依赖声明，这其实在html/css/js的关注点足够分离、三者耦合度足够小的项目中，对代码有极强的侵入性，一旦开始，代码将很难面向其它非webpack方式去组织了。

而这种方式，则完全规避了大量手工对任务的划分，因为webpack提供的任务都是放在依赖关系的基础上来执行的。

---

好。怎么选择呢？首先是 task runner，如果项目从零开始，直接用webpack吧；项目形成了成型的文件夹管理方案，耦合被控制得很好，使用webpack将非常痛苦，毕竟需要推翻原有的模式而使用js作为入口，gulp是一个很好入手的方案。不过就 task runner 的管理难度而言，项目越大，webpack带来的好处将越明显。

打包层面，你会发现过去无论是requirejs的r.js、cmd的browserify都已经沉寂多年，webpack出来以后所有社区的热点都转向了webpack。从这个意义来讲，想要能够保证有充足社区支持的环境中进行打包，最好还是学会使用webpack。（尽管它的文档是我见过可能存在的最糟糕的文档之一，可能没有之一。）