常见构建工具及其对比|前端工程化

下面，我们讲一下如何将工程化能力应用在构建阶段，主要介绍几种常见的构建工具以及 polyfill、Babel。最后针对目前最流行的构建工具 webpack 的配置优化。

# 为什么需要构建

既然要了解在构建过程中的工程化手段，那么首先我们要知道什么是构建，为什么在前端项目中需要构建。

在编程领域，我们普遍认为编译是将源代码经过一系列处理转换为机器语言（汇编）的过程。构建指的是将我们在开发环境写的代码，转换成可交付的生产环境的代码的过程，其中包括了编译。

记得大学时候《网页开发》这门课的时候，老师给我们讲，网页开发的一大优势就是开发便捷，HTML\JavaScript\CSS 不需要编译就可以直接在浏览器中运行，我们甚至可以使用记事本来进行前端开发，所以，最原始的前端是不需要编译过程的。

在 JQuery 之前的时代，浏览器厂商还没有多，不需要处理各种各样的兼容性问题。前端所做的工作只是写一些简单的 HTML\JS\CSS 代码，也不需要编译，可以直接打开 .html文件在浏览器中运行。

到了 JQuery 时代，虽然市面上已经有各种各样的浏览器，但是 JQuery 已经帮我们解决了绝大多数的兼容性问题，我们只需要引入 JQuery 的源码就可以忽略浏览器兼容性带来的问题，也可以直接将开发的代码在浏览器环境下运行。

那么为什么现代前端开发，我们就需要构建过程呢？

首先是在现代前端开发中，我们需要使用最新的 ES6\7\8 语法、我们需要使用 TS 来进行类型管理，我们需要使用 Less/Sass 辅助我们开发 CSS。这些新技术在提升开发效率的时候，会有一个共同的问题：无法直接在浏览器中解析（或者部分浏览器不支持）。所以，我们就需要在开发的时候加入编译的环节，将我们开发的代码编译为浏览器可识别、可运行的代码。

其次是在模块化发展起来之后，我们将模块\组件的粒度拆分的更细，方便开发的同时也引入了新的问题，每一个文件都会被引入到 HTML 文件中，用户在使用浏览器访问页面的时候就会增加请求数量。想象一下，一个中型项目的开发，拆分出来的组件少则几十个，多则上百个。如果不进行文件合并，那么在性能上，会严重增加用户的等待时长。 所以我们为了减少请求次数，还需要将所有小文件“打包”为一个或多个大文件。

最后在我们项目发布上线的时候，我们需要保证项目整体的可交付性和可维护性。可交付性主要需要进行单元测试来保证代码质量、需要使用 ESLint 等代码规范约束工具对代码进行检查；可维护性主要需要对代码压缩、混淆、合并来减少代码体积和请求数量来保证性能问题。

所以构建就是将我们平时开发的源代码转换为可交付的代码，主要的过程有以下几点：

• 编译：将源代码转化为浏览器可执行代码，例如 .jsx、.vue文件转换、.sass文件转换为 css 文件。
• 代码校验：使用例如 ESLint 等工具自动检测代码格式是否符合团队要求。
• 文件优化：删除未引用代码（tree-shaking）、压缩文件体积、合并文件、制作“雪碧图”、代码混淆等。
• 自动化测试：自动化执行测试用例，进行单元测试或快照对比。

工程化在构建的过程要做的事情就是将这一系列的流程用代码控制，自动执行这一系列负责且耗时的重复劳动。在发展的过程中，也涌现出了一系列的前端构建工具，比如 Gulp、Grunt、Webpack、Rollup 等，下面我们就分析下几种常见的构建工具及其优缺点。

# npm script

在前面《探索 npm 安装机制》中，我们简单的介绍了 npm 相关的内容。npm 是 nodeJS 内置的包管理工具，而 npm script 是 npm 内置的自定义脚本执行命令。其允许你在 package.json 中使用 script 字段定义脚本。比如，我们想在开发时运行 dev.js 文件，我们就可以这样设置：

{
  "scripts": {
    "dev: "node dev.js",
  },
}

然后在终端中运行 npm run dev，就会对应执行 dev.js 中的内容。

在 package.json 的 script 对象中，每个属性对应一个 shell 脚本，每当执行 npm run xxx的时候，都会新创建一个新的 Shell 执行对应的命令。

npm scripts 的优点是方便快捷，只要是 Shell 可以执行的命令，都可以写在 npm scripts 中。并且不需要安装其他依赖。但是缺点也很明显，功能单一，无法进行一些复杂的功能。

# Grunt

Grunt 和 npm script 类似，都可以认为是 JavaScript 的任务运行器。和 npm scripts 不同的是，Grunt 有丰富的插件体系，可以使用其内置的或者社区中的封装了常见任务的插件。Grunt 还可以管理任务之间的依赖关系，自动化执行任务。

Grunt 需要在配置文件 gruntfile.js 中配置每个任务具体的执行代码和依赖关系。例如，我们创建一个 jshint任务，对 Gruntfiles.js 和 src源码以及测试用例 test 文件夹下所有的 .js 文件进行监听，如果有变动的话就执行 jshint这个任务（task）。需要的插件依赖有：grunt-contrib-jshint、grunt-contrib-watch，在启动 gunt 的时候就默认注册 jshint任务。

我们可以做如下配置：

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 时需要注册哪些任务
  grunt.registerTask('default', ['jshint']);

};

然后在根目录下执行 grunt dev就会启动 grunt 并执行注册的 task。

Grunt 的优点和 npm scripts 一样，方便快捷，并且社区也有丰富的插件资源，Grunt 已经到了发展的成熟阶段，一般的构建任务需求都可以找到成熟的解决方案。其灵活性也可以让你自由配置想要的任务。Grunt 的缺点就是配置略为繁琐。

# Gulp

Gulp 也是一款老牌的自动化构建工具，和 npm scripts、Gunt 这样的任务运行器不同的是，Gulp 引入了 stream（流）的概念，底层使用 node 强大的 stream（流）能力，提高构建速度。

基于其 stream 的能力，gulp 也有一套自己的生态插件处理 stream，比如我们想要将 less 源文件编译为 css 文件可以如下设置：

• 先引入依赖模块
• 在通过 gulp.task 创建 less 任务
• 然后使用 gulp.src 读取 less 文件，将读取到的文件交给 less 模块插件处理，处理完的结果使用 gulp.dest 输出为 css 文件。
• 然后我们再使用 gulp.watch 设置监听任务，当 less 文件变化的时候，就执行 less 任务。

gulpfile.js 配置文件如下：

// 引入依赖模块
const gulp = require('gulp');
const eslint = require('gulp-eslint');
const less = require('gulp-less');

// 创建 less 任务，将 less 源文件经过过 less 依赖的处理，流式处理并输出 css 文件
gulp.task('less', function() {
  gulp.src('./less/*.less')
    .pipe(less())
    .pipe(gulp.dest('./css'));
});

// 监听文件，当 less 文件变化时执行 less 任务
gulp.task('watch', function() {
  gulp.watch('./less/*.less', ['less']);
  gulp.watch('./js/*.js', ['scripts']);
})

Gulp 和 Grunt 类似，也经常拿来比较，两者的相同之处是都引入的 task 任务的概念，Gulp 吸取了 Grunt的优点的同时，有着更简便的写法，通过流（Stream）的概念来简化多任务之间的配置和输出，让任务更加简洁和容易上手。但是 Gulp 和 Gunt 相同的缺点都是集成度不高，需要很多的配置文件，不能开箱即用。

# webpack

终于来到了 webpack 的时代！上面的 Grunt、Gulp 你可能没有听说过，但是 webpack 你一定不会没有听说过。

本质上，webpack 是一个用于现代 JavaScript 应用程序的 静态模块打包工具，使用 webpack 处理应用程序时，需要一个入口或多个入口文件，根据入口文件可以递归寻找出其依赖文件，构建出一个依赖图，然后将你项目中所需的每一个模块组合成一个或多个 bundles，它们均为静态资源，用于展示你的内容。

在 webpack 中，一切的资源：JS\CSS\IMG 等，都是一个个的模块，可以通过 Loader 进行文件转换、Plugin 插件系统进行文件处理，最后对模块进行组合和打包，输出浏览器可以使用的资源。

比如，我们使用 raw-loader 让静态资源内联，然后使用 HtmlWebpackPlugin 插件，为应用程序生成一个 HTML 文件，并自动将生成的所有 bundle 注入到此文件中。那么我们可以做如下配置：

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin'); // 通过 npm 安装

module.exports = {
  entry: './path/to/my/entry/file.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'my-first-webpack.bundle.js',
  },
  module: {
    rules: [{ test: /.txt$/, use: 'raw-loader' }],
  },
  plugins: [new HtmlWebpackPlugin({ template: './src/index.html' })],
};

webapck 的优点有很多，最值得一提的应该是其强大的功能，只有你想不到，没有 webpack 做不到 ´ヾ(=･ω･=)o。并且有着丰富的社区资源，社区庞大且活跃。webpack 还可以做到开箱即用，有着良好的开发体验。说到不足之处的话，因为其功能强大，所以配置信息也较为庞大，上手成本虽然简单，但是想要精确需要深入研究，webpack 配置工程师名不虚传！

# Rollup

Rollup 是一个 JavaScript 模块打包器，可以将小块代码编译成大块复杂的代码。Rollup 和 webpack 类似，但是但 Rollup 更为小巧，可以充分利用 ESM 各项特性的高效打包器。

其配置信息十分简介和便于理解，下面是一个常见的配置信息：

# 总结