前端开发构建：13 种热门工具的选型参考

前言

在前端项目的规模和复杂性不断提高的状况下，各种构建思想和相应工具层出不穷。本文竭己所能对比了当下13个构建工具，包括 Browserify、 Webpack、 Rollup、 Grunt、 Gulp和 Yeoman6个广为流行的工具， FIS、 Athena、 WeFlow和 Cooking等4个国产工具，以及三大框架： React， Vue和 Angular的官方脚手架。但愿能在项目初期的构建工具选型上为你们提供些参考。

全览

构建工具能够分为三类：模块化打包类、任务流构建类和集合型工具类（脚手架）。其中最为突出的，当属用于模块化打包的 Webpack和用于任务流构建的 Gulp。下面是截至2018年11月28日某时某刻， GitHub上各个工具的 Star数目（据说 Star数目能够造假？好生无聊的家伙们！）。

前端的构建通常包括JS转码（使用 Babel转 ES6或 TypeScript自转等）、CSS转码（ Less或 Sass转 Css）、代码或资源的合并与压缩，基础检查和各种测试等等。这些虽与本文关系密切，但都不在讨论的范围以内。缘由有二：一是实现这些功能的都是某些插件，不是工具自己，各种构建工具都是直接或间接（调用以本身的模式封装后的插件）使用它们的；二是本文介绍的是，构建方向上的类别和各种别里不一样工具间的差别，与具体的操做无关。

模块化打包类

如今的前端项目基本是模块化的，缘由就不在这多说。而模块化意味着分散，没法直接用于呈现，所以须要进行相应的打包造成一个总体。有些执行环境（ Node）能自动打包各个模块，而有些（浏览器）则由于技术或其它考虑须要自行操做。模块化打包工具就是为模块化项目在浏览器上的优化呈现而服务的。

模块化打包的核心是：找出依赖，打包成体。各种工具的基本运行思路即是根据已有配置，从某个文件开始，递归的找出全部与其相关的依赖模块，打包成某种类型的可直接在浏览器中运行的一个或多个新文件。这之中还能够优化输出，以实现代码分离、异步加载和长效缓存等高级功能。

对web开发技术感兴趣的小伙伴，欢迎加入：前端学习圈，无论你是小白仍是大牛我都欢迎

Browserify

[](http://browserify.org/) | GitHub

正如其官网介绍的， Browserify会递归的分析，项目中全部使用 require引入的JS模块（包括 Node内置模块）并打包，使得 Node类项目能在浏览器上运行。不过对于与项目有关的其它资源，好比 Css和图片等，依然须要手动管理。虽然网上已有人编写了支持此些功能的插件，但这不只违背了设计初衷，也使配置变得杂乱。并且对于要求愈来愈高的单页面应用来讲，它能提供的助力着实已显疲惫。

Webpack

[](https://webpack.js.org/) | 中文 | GitHub

稳定版已到 v4.26.0，本文以此版本为据。另附加官方的对比文档。

Webpack的设计思想新颖实用，社区活跃，功能强大全面，已是针对前端各种资源的、目前最优秀的模块化管理和打包工具。它入门简单，基本的经常使用功能能很快上手，并用于实际开发。但精通不易，毕竟打包已经是 web开发中最重要的挑战之一，必然要耗费些许精力。学习尚且不易，介绍就更为困难，得要有一本书的厚度。所幸此节不是详细介绍，只是亮点阐述，善哉善哉。

入门已趋简单

掌握了构建的基本思路，任意工具的入门都是较为简单的（读者批：废话）。之因此强调 Webpack入门简单，是为了减轻有意者学习以前的顾虑。一方面是它刚被推出时，因为自身的概念新颖并且文档不全面，使开发者处于懵懵懂懂的状态，总感受离真谛还差些距离。另外一方面是它的体系着实庞大，仔细想一想都难免胆怯。笔者初次接触时即是这些个感觉。

但如今不同。吃土的日子已经远去，啃草的梦想还会远吗？你们准备好镰刀！

Webpack第四版在入门上的方便性体如今三方面。一是基础功能高度集成和约定优于配置思想：安装好 Webpack及其 CLI后即可直接打包 JS和 JSON文件，与 Browserify同样简单。二是官方文档详细（并且有基本同步的中文版），不管是概念的解析、实际运用的示例仍是接口的展现都十分完备。三是如今使用和介绍 Webpack的人已经不少了，所以网上的各路资料和相应问题的解决方案都十分丰富。你还在犹豫？

一切皆模块

如从官网上截取的图片所示，在 Webapck眼中一切文件（ .js、 .css、 .jpg、 .woff、 .csv和 .ts等除了某些用于下载的静态大文件外）都是模块，都能经过与 JS类似的方式被打包，并安置于合适浏览器渲染的位置。真是十分优秀的立足点。以此思想即可囊括前端会使用到的几乎全部资源，能够十分方便的统一管理和安置，更为便捷和高效。

并且此思想就是为单页面应用而生的。在 Webpack的另外一层意境中，一个 asset（各种资源）是一个模块，一个 component是一个模块，一个 module也是一个模块。而单页面应用的特色，不就是应用的更新不是整个页面的更新，而是某个 module或 component或 asset的更新吗？十分的契合。

有人说 Webpack的缺点在服务端渲染（或说多页面应用）上。喂喂，一来别人的目标本就不在此，二是多页面应用也不须要如此复杂的支持体系。

高效的构建性能

单页面应用或说须要构建才能展现的应用，相比多页面应用，从每次修改到从新呈现要多经历一个构建的阶段。实际操做中，若是项目庞大而构建性能不够优化，一个小小的修改（打印某值）都会消耗5秒以上的时间，对开发者来讲真是个地狱！而优化的方法不外乎两点，一是开发者优化项目的构建思路，二是构建工具优化自身的构建性能。

Webpack拥有较理想的构建性能。在开发阶段，当开启了 Webpack的模块热替换以后（使用 webpack-dev-server会自动开启），一旦检测到文件被修改，会在应用程序运行过程当中经过冒泡捕获的方式最小化替换、添加或删除模块，而无需从新加载整个页面。相似 Dom渲染中的回流：若是子元素发生的大小变化，会影响兄弟元素但不影响父元素，那么父元素及其它是无需从新绘制的。并且即使彻底从新构建，也会保留先前的应用程序状态，减小等待时间。

活跃的社区

活跃的社区能够提高系统的丰富度，下降学习与使用的成本。

Webapck社区十分活跃，应用于各类需求的插件都被一一封装而可直接使用（官方也统一展现和说明了一些经常使用的优秀的 Loader和 Plugin）。不仅仅是其它工具的高度协调，开发中的各个阶段：搭建本地服务器、集成测试等，以及与任务流工具（ Gulp、 Grunt）的集成等等方面的解决或最优方案，都是丰富和全面的。基本上能够想到的需求，在这个社区中，都能直接借鉴他人已有的成果。

Rollup

[](https://www.rollupjs.com/guid... | 中文 | GitHub

Rollup定位为一个 JS模块打包器（明指 JS），主要用来构建 JS库，也可服务于一些无需代码拆分和动态导入的小型应用程序。能在 Webpack已稳居打包之首的状况下杀出一条血路，获得 Vue、 D3、 Three和 React等著名库的青睐，想必其着手点和性能有过人之处。

Rollup自己结构简单，须要的配置项也很少，再加文档全面，因此很容易上手并所有掌握。它使用 ES6自己的 Module语法做为本身的标准，而不是诸如 CommonJS和 AMD等之前的解决方案。这意味着按照 Module标准编成的代码，不只如今能够借助 Rollup打包运行，将来更能在实现此标准的浏览器上直接运行。

经过 Module的特性， Rollup开创了 Tree-shaking功能——清除没有在项目中使用到的代码。它基于显式的 import和 export语句的方式，经过静态分析，排除了任何未在实际中使用的代码，能极大的减小构建于已有模块的项目体积。再加上其构建基本不添加自身的控制代码，使打包后的文件真正的达到纯净二字。想一想还有点痒痒，我挠挠裆部。

与 Webpack 对比

Rollup和 Webpack因其定位和专一点是能够共同存在并相互支持的。

正如 Rollup官网所说的， Rollup更适合构建独立的 JS库，而 Webpack为资源丰富的应用程序。虽然 Webpack也增长了本身的 Tree-shaking功能，但在编译后的输出代码中，简单地运行自动 minifier检测未使用的变量，获得的结果是不如原生的静态分析。更况且 Webpack生成的代码必定是通过本身包装后的代码——将每一个模块封装在一个函数中，再置于一个包中，经过浏览器能使用的 require方式逐一执行这些模块。

任务流构建类

基于任务的构建行为，是不在意操做对象是否为模块化的。

这类工具的目标是经过配置来解放平常须要重复的工做——转化、合并压缩和单元测试等等。有人说：这些操做 Webpack和 Rollup不是也能作？是的，基本能作。实际上，在用模块化构建工具的开发中，不多会用到任务流构建工具。但这毫不是说任务流工具会被取代，也不会被取代，至少多页面应用须要。再说任务流工具是十分纯粹的自动化行为，与模块化打包工具立足点就不同，何谈取代一说。

Grunt

[](https://gruntjs.com/) | 中文 | GitHub

Grunt虽是老牌构建工具，但依然被许多知名项目如 WordPress、 Twitter和 Jquery等使用，也拥有持续更新的完整生态圈和中文文档。它是经过配置驱动——经过获取到的 JSON配置执行操做，来流水线式执行相应任务。虽然在学习成本和执行效率上不出众，但若是项目本来就是经过它自动化构建的，是没有必要迁移到其它工具的。

// Grunt 的配置驱动示例module.exports = function(grunt) {  grunt.initConfig({    jshint: {      files: ['Gruntfile.js', 'src/**/*.js', 'test/**/*.js'],      options: {        globals: {          jQuery: true        }      }    },    watch: {      files: ['<%= jshint.files %>'],      tasks: ['jshint']    }  });  grunt.loadNpmTasks('grunt-contrib-jshint');  grunt.loadNpmTasks('grunt-contrib-watch');  grunt.registerTask('default', ['jshint']);};

Gulp

[](https://gulpjs.com/) | 中文 | GitHub

Gulp是新型的构建工具，虽与 Grunt的功能相同，但其构建过程却有三大优点。

代码驱动

代码驱动即经过执行实际代码驱动程序执行，与常见的配置驱动不一样（ Webpack、 Rollup和 Grunt等都是配置驱动）。从任务流构建的角度上看，代码驱动相比配置驱动有三点好处：一是高度的灵活；二是没有过多的配置项，减小学习成本；三是更方便错误的判定和异常状况的调试。

// Gulp 的代码驱动示例gulp.src('./client/templates/*.jade')  .pipe(jade())  .pipe(gulp.dest('./build/templates'))  .pipe(minify())  .pipe(gulp.dest('./build/minified_templates'));

Node流

Gulp做为后来者，充分利用 NodeJS流的思想进行 IO操做，极大增长了大型项目的构建速度。比方说转化 Scss成 Css， Grunt的操做流程是：读取 Scss文件、转化成 Css、存储到磁盘，读取 Css、压缩处理最后存储到磁盘；而 Gulp得操做是：读取 Scss文件、转化成 Css、压缩处理最后存储到磁盘。一步到位，无需屡次的 IO操做。

简单明了

Gulp有十分精简的 API。你能想到各类类型的任务，基本是经过仅有的五个可链式操做的方法实现的吗？不只仅是学习和使用方便，编写后的功能也是一目了然。虽然代码驱动相比配置驱动，须要本身写的代码增长，但一是没增长难度只是函数名的屡次重写，二是相对代码驱动的好处来讲能够忽略。

集合型工具类

集合型工具类即是常说的脚手架，也能够看做是以模块化或任务流工具为主体的，各种经常使用工具的高度封装。它是一个开箱便可用的集合体，相似先后端同构时代的后端框架。它会根据你的选择，生成一个完整的、已配置好各种工具的、具备某些特定代码约定的项目框架。这些配置几乎包揽前端开发的整个流程，甚至能够集成自动化部署等后端接口。

官方框架

[](https://facebook.github.io/cr... | Vue CLI | Angular CLI

集合型工具通常为单页面应用服务，而单页面应用须要使用某个前端框架。不管你是用 React、 Vue或 Angular，仍是其它框架，首先得想到它是否有官方脚手架。好比 Vue有 VueCLI。通常推荐有官方脚手架的直接使用官方的。由于现代前端框架通常不单独运行，需结合官方提供的其它工具，好比路由、状态管理等。并且各个框架及配件更新不断，每次更新均可能致使与其它插件的兼容问题，新的功能可能须要某些特定插件才能发挥做用。这是一项工程，仅靠我的或某些团体很难照顾周全的。而各个框架又都有意识的经过官方脚手架来充分展现新的特性，下降学习和使用的成本。咱们何乐而不为呢？

对web开发技术感兴趣的小伙伴，欢迎加入：前端学习圈，无论你是小白仍是大牛我都欢迎

Yeoman

[](http://yeoman.io/) | GitHub

Yeoman是一个专为现代前端而生的、灵活通用的脚手架工具。

它的运做方式和其它脚手架不一样。在安装好 CLI后，须要找到一个符合要求的 Generator（一个 npm包，至关于脚手架），使用 Yeoman运行安装，生成初始化的项目。你也能够自行配置，使用 Yeoman封装成符合特定需求的 Generator，并发布出去。等到下次，其余人或你本身，须要生成符合此要求的项目时，即可以直接安装并使用 Yeoman生成。

这样有明显的两点好处：一是节省体力。在开始一个有特定需求的新项目时，若是有老项目可借鉴，通常会直接复制相关文件。但这样的复制文件可能不纯粹，即增长体积又带来安全隐患。二是在社区的支持下，不少有特殊要求的脚手架，早已有人解决并发布成 Generator，是不必本身动手的。

国内其它

百度 - FIS - 官网 | GitHub 
微信 - WeFlow - 官网 | GitHub 
京东 - Athena - 官网 | GitHub 
饿了么 - Cooking（名字与公司的性质相得益彰） - 官网 | GitHub

做为程序员或至各行各业，在与年龄增加速度至关的压力下，工资的高低天然成为平常性的评定标准。但在同行老友的酒桌上或某个太阳异常温煦下的小道上，能使本身为本身而不是其余事骄傲的，也确定是“老子以前作过些什么”之类的实际付出而不是物质方面的得到。所以可以成为被公司支持的、被众多人使用的、开源框架维护团队中的程序员，多少是更为幸福的一类。

这些由国内各个前端团队开发的集合型脚手架，都是基于自用在实践中获得的最为符合自己需求的产品。里面的包含内容十分丰富，不只仅是这以上提到的前端本职工做，还有与后端的集成方案或自动化部署配置等。且流程简化，开箱便可使用。不过这些笔者都没用过，也没有打算用。不是打趣，缘由很现实，有识之士能够在文章下留言。不用却依然写出的缘由却是简单：宣传，宣传即赞许和期盼；凑数，凑到13种好立个多少浮夸的标题。

总结

我的观点，不喜请喷，但要和善可亲。

若是是使用某个前端框架开发应用程序，推荐框架官方的脚手架。若是是本身头脑发热想开源个 JS库，推荐 Rollup打包。若是不是模块化项目，又须要自动化处理一些事情，推荐 Gulp做为构建工具。若是项目有特殊要求或做为核心的部件比较稀有，能够先查看 Yeoman上是否有符合要求的 Generator，没有就只能自食其力。最后若是你处在已有本身脚手架的公司（好比饿了么），可能要按规章制度使用 Cooking为本身的仕途烹煮些吃食。

最后，若是是自食其力的搭建前人没有的脚手架，推荐使用 Yeoman发布，方便你我他。