为什么要在任务运行器(grunt)上使用模块捆绑器(webpack)？

Question

在过去,我使用了一个yeoman-generator Grunt来完成我的所有开发任务.通常在处理项目时我会用指南针来编译我的scss,然后打包和uglify我的JS,优化图像,lint我的代码,以及许多其他有用的东西.

最近我看到了人们使用webpack而不是grunt插件来实现其中许多任务的趋势.为什么是这样？在这方面,模块捆绑器有什么好处？

Answer 1

我确定其他人有他们的理由,但我迁移到webpack(更具体地说是webpack-dev-server)的最大原因是因为它从内存(而不是磁盘)服务你的捆绑包,它的观察者只会重新编译重新使用缓存中的其余文件时更改的文件(在记忆中).这使得开发速度更快.我的意思是,当我正在积极编辑代码时,我可以在Sublime Text中按ctrl + s,当我将alt + tab添加到Chrome时,它已经完成了重建.之前我有一个grunt + browserify + grunt-watch设置,每次保存时都需要至少5秒钟重建(这是在我在grunt构建中进行了一系列专门的优化之后).话虽这么说,我仍然将webpack与gulp集成在一起,所以我为我的项目获得了一个任务运行器.

编辑1:我还想补充一点,旧的咕噜声+ LESS/SASS + browserify + uglify + grunt-watch设置不能很好地扩展.我从头开始从事一个重大项目.起初它很好,但随着项目的增长,它每天都变得更糟.最终,等待咕噜声完成构建每个ctrl + s变得异常令人沮丧.显然,我正在等待一堆未更改的文件.

另一个不错的小东西是webpack允许你在.js中需要样式表,它在同一个模块中建立了源文件的耦合.最初我们通过在.less文件中使用import来建立样式表依赖项,但是在同一模块中断开了源文件并建立了单独的依赖图.所有这些都是高度自以为是,这只是我个人的意见.我相信别人会有不同的想法.

编辑2:在下面的一些讨论之后,让我试着提供一个更简洁,更少见解的答案.webpack做得非常好的一件事是可以观看,读取,预处理和更新缓存,并以最少量的文件I/O和处理进行服务.Gulp管道工作得非常好,但是当涉及到捆绑步骤时,它不可避免地必须从temp目录中读取所有文件,包括那些未更改的文件.随着项目的增长,此步骤的等待时间也会增加.另一方面,webpack-dev-server将所有缓存都保存在内存中,因此开发期间的等待时间保持最小.但是要实现这种内存缓存,webpack需要从手表到服务器覆盖,因此需要知道您的预处理配置.一旦你配置webpack来做到这一点,你可能只是重复使用相同的配置来吐出除dev服务器之外的构建.所以我们最终陷入了这种境地.话虽这么说,你想让webpack做什么步骤仍然取决于你的个人喜好.例如,我不在我的开发服务器中进行图像处理或lint.事实上,我的棉绒步骤是一个完全独立的目标.