Blade是腾讯为了解决GNU Make使用繁琐的问题而开发的一个开源构建工具，旨在简化大型项目的构建，能够自动分析依赖，集成了编译、链接、测试、静态代码检查等功能，支持C/C++, Java, Python, Scala, protobuf等多种语言（主要面向C/C++）。

注意：构建(build)和编译(compile)不同，编译器负责将源代码转换为库文件或可执行文件，构建工具负责分析库之间的依赖关系，并调用编译器来生成构建目标。

例如，自己的代码依赖A库，A库又依赖B库，如果手动编译则需要写复杂的编译和链接命令，当依赖库代码发生变化时还需要重新编译，构建工具旨在自动化这一过程。

项目主页：https://github.com/chen3feng/blade-build
官方文档：https://github.com/chen3feng/blade-build/blob/master/doc/en/README.md
用户手册：https://github.com/chen3feng/blade-build/blob/master/doc/blade_user_manual.pdf
介绍ppt：https://github.com/chen3feng/blade-build/blob/master/doc/blade.pdf

1.特性

• 自动分析库之间的依赖关系
• 递归构建：当依赖库的源文件发生变化时会自动重新构建依赖库，而GNU Make无法实现递归构建
• 增量构建：未发生变化的依赖库不会重新构建，加快构建速度
• 提供了对protobuf和测试（使用gtest）的内置支持

2.依赖软件

Blade需要以下依赖：

• Linux或Mac操作系统
• Python 2.7
• Ninja 1.8+

构建特定语言所需的编译器：

• C/C++: gcc 4.0+
• Java: JDK 1.6+
• Scala: 2.10+

3.安装

3.1 安装Python

Linux或Mac系统默认已经安装了Python 2.7。

3.2 安装Ninja

下载地址：https://github.com/ninja-build/ninja/releases

解压后只有一个可执行文件ninja，将其放到PATH环境变量包含的某个目录下（例如/usr/local/bin），从而能够直接在命令行中直接执行ninja命令：

$ ninja --version
1.10.2

3.3 安装Blade

安装方式：下载源代码，执行install脚本

$ git clone https://github.com/chen3feng/blade-build.git
$ cd blade-build/
$ git checkout v2.0
$ ./install

执行完成后Blade将被安装在~/bin目录下，该目录也被添加到PATH环境变量，执行source ~/.profile命令或重启终端使其生效，此时应该能够在命令行中直接执行blade命令：

$ blade -h
usage: blade [-h] [--version] {build,run,test,clean,query,dump} ...

blade <subcommand> [options...] [targets...]
...

注意：不能删除blade-build目录，因为blade命令会用到其中的源代码。

4.简单示例

下面使用Blade创建一个hello-world项目。

官方文档：https://github.com/chen3feng/blade-build/blob/master/doc/en/quick_start.md

4.1 创建工作目录

$ mkdir hello-world
$ cd hello-world/
$ touch BLADE_ROOT

其中项目根目录hello-world可以在任意位置，BLADE_ROOT文件用于标识项目根目录。

4.2 实现say库

在hello-world目录下创建头文件say.h：

#pragma once
#include <string>

// Say a message
void Say(const std::string& msg);

创建源文件say.cpp：

#include "say.h"
#include <iostream>

void Say(const std::string& msg) {
    std::cout << msg << "!\n";
}

这两个文件组成了一个库(library)，可以将其编译为库文件供其他代码使用，创建一个BUILD文件来描述say库：

cc_library(
    name = 'say',
    hdrs = ['say.h'],
    srcs = ['say.cpp'],
)

其中cc_library表示这是一个C/C++库，hdrs表示该库的公共接口头文件，srcs表示该库的源文件。

4.3 实现hello库

下面创建另一个库hello，并调用say库提供的函数。

创建头文件hello.h：

#pragma once
#include <string>

// Say hello to `to`
void Hello(const std::string& to);

创建源文件hello.cpp：

#include "hello.h"
#include "say.h"

void Hello(const std::string& to) {
    Say("Hello, " + to);
}

其中函数Hello()的实现调用了say库提供的函数Say()，因此hello库依赖say库。

在BUILD文件中添加hello库的定义：

cc_library(
    name = 'hello',
    hdrs = ['hello.h'],
    srcs = ['hello.cpp'],
    deps = [':say'],
)

其中deps表示该构建目标的依赖，:say表示当前BUILD文件中名为say的目标，即前面的say库。

4.4 实现hello-world程序

下面创建一个hello-world程序，在main()函数中调用hello库提供的函数来打印信息。

创建hello_world.cpp文件：

#include "hello.h"

int main() {
    Hello("World");
    return 0;
}

在BUILD文件中添加hello-world的定义：

cc_binary(
    name = 'hello-world',
    srcs = ['hello_world.cpp'],
    deps = [':hello'],
)

这里的规则名称是cc_binary，表示该构建目标的产出是一个可执行程序。

注意：依赖只需要添加hello，而不需要添加say，因为这是hello库的实现细节，在编译和链接过程中Blade会自动处理这样的传递依赖。但如果hello_world.cpp中显式包含了say.h，则依赖中需要添加say。

下面构建并运行hello-world程序：

$ blade build :hello-world
$ blade run :hello-world
Hello, World!

注：如果安装的是最新版本的Blade，这里会报错Blade(error): Target “//.:hello-world” does not exist，解决方法是切换到v2.0版本重新安装。

blade build命令底层了调用g++编译器和ld链接器，生成的库文件和可执行文件在build64_release目录下。blade run命令就是运行生成的可执行文件build64_release/hello-world，可使用--verbose参数查看具体执行的命令。

注：对于这个简单的示例，直接执行

g++ -o hello_world hello_world.cpp hello.cpp say.cpp

即可完成编译，但是对于具有上百个源文件的大型项目，使用构建工具就很有必要了。

完整的项目目录结构如下：

hello-world/
    BLADE_ROOT
    BUILD
    hello_world.cpp
    hello.cpp
    hello.h
    say.cpp
    say.h

注：该示例将所有头文件和源文件都放在项目根目录下，实际的项目中会按模块将文件分为不同的子目录，每个子目录下都包含一个BUILD文件。

完整代码：https://github.com/chen3feng/blade-build/blob/master/example/quick-start

example目录下也有其他示例

5.代码组织结构

Blade要求项目有一个显式的根目录，即BLADE_ROOT文件所在目录，根目录下是自己的模块子目录和第三方库目录，每个子目录下都有一个BUILD文件来声明该模块所包含的一个或多个库。

以下是一个示例目录结构：

my-project/
    BLADE_ROOT
    common/
        string/
            BUILD
            algorithm.h
            algorithm.cpp
    foo/
        BUILD
        foo.h
        foo.cpp
    thirdparty/
        gtest/
            BUILD
            gtest.h
            gtest.cc
            ...

（这是Google推荐的源代码管理方式：所有代码放在同一个仓库中，包括第三方库代码）

代码中#include头文件的相对路径和BUILD文件中依赖的相对路径都是基于项目根目录的
例如：common/string/BUILD声明了一个string库，包括头文件algorithm.h，则在foo/foo.h中通过#include "common/string/algorithm.h"包含该头文件，在foo/BUILD中通过'//common/string:string'声明依赖

6.BUILD文件

Blade通过一系列名为BUILD（全部大写）的文件指定构建目标，每个构建目标由一些头文件和源文件组成，其他构建目标可以依赖这个目标并引用其头文件。

BUILD文件中只需要指定目标所包含的头文件、源文件和直接依赖，执行构建命令时Blade将自动分析依赖关系，并调用编译器和链接器来生成构建目标。

6.1 示例

假设common/string目录下定义了一些字符串辅助函数，并且依赖common/int目录下的int库，则common/string/BUILD文件如下：

cc_library(
    name = 'string',
    srcs = [
        'algorithm.cpp',
        'concat.cpp',
        'format.cpp',
    ],
    hdrs = [
        'algorithm.h',
        'concat.h',
        'format.h',
    ],
    deps = ['//common/int:int'],
)

其他库在依赖中通过'//common/string:string'引用该库。

（BUILD文件可理解为Python函数调用语法）

（抄的Bazel？）

6.2 风格建议

• 缩进4个空格
• 使用单引号而不是双引号
• 目标名称使用小写
• srcs中的文件按字母顺序排列
• deps先写当前目录下的依赖(:name)，再写其他目录下的依赖(//path/to/dir:name)，按字母顺序排列
• 当每行一个参数时，最后一个参数也以逗号结尾，从而减少当增加或删除参数时影响的行数
• 不同目标之间空一行，每个目标前添加注释，注释以#开头

6.3 构建目标类型

Blade支持多种类型的构建目标，每种构建目标用于不同的语言、调用不同的编译器、产出不同的结果。以下是几种常用的构建目标的语法。

完整列表参考：https://github.com/chen3feng/blade-build/blob/master/doc/en/build_file.md#build-rules

6.3.1 cc_library

构建C/C++静态链接库，C文件(.c)使用gcc编译器，C++文件（.cpp、.cc等）使用g++编译器，使用ld链接器，生成静态链接库文件(.a)。

语法（仅包含了常用属性）：

cc_library(
    name ='foo',
    hdrs = ['foo.h', 'bar.h', ...],
    srcs = ['foo.cpp', 'bar.cpp', ...],
    deps = [':name', '//path/to/dir:name', ...],
)

• name：构建目标的名称，和当前目录一起构成目标的唯一标识
• hdrs：公共接口头文件列表（私有头文件应声明在srcs中），如果只有一个则可省略中括号
• srcs：源文件列表，位于当前目录或当前目录的子目录下，如果只有一个则可省略中括号，可使用glob函数
• deps：依赖目标列表，支持以下格式：
  • //path/to/dir:name：项目根目录下path/to/dir/BUILD文件中定义的名为name的目标（看到就知道它在哪）
  • :name：当前BUILD文件中名为name的目标
  • #name：系统库
• visibility：对哪些目标可见（在Blade 2中，目标默认是私有的，即只对当前目录下的目标可见，可使用visibility = ['PUBLIC']指定对所有目标可见）

6.3.2 cc_binary

构建C/C++可执行文件（即包含main函数的程序）。

语法：

cc_binary(
    name ='foo',
    srcs = ['foo.cpp', 'bar.cpp', ...],
    deps = [':name', '//path/to/dir:name', ...],
)

6.3.3 cc_test

C/C++单元测试，使用GoogleTest测试框架。

语法：

cc_test(
    name = 'foo-test',
    srcs = ['foo_test.cpp'],
    deps = [':foo'],
    testdata = ['test.txt'],
)

TODO 具体用法链接GoogleTest博客

6.3.4 proto_library

构建Protocol Buffers库，使用protoc编译器。

语法：

proto_library(
    name = 'student_proto',
    srcs = 'student.proto',
    deps = ':base_proto',
)

见Protocol Buffers入门教程。

7.命令行参考

官方文档：https://github.com/chen3feng/blade-build/blob/master/doc/en/command_line.md

Blade命令行语法：

blade <subcommand> [options...] [targets...]

7.1 子命令

• build：构建指定的目标
• run：构建并运行指定的目标
• test：构建指定的目标并运行测试
• clean：删除指定目标的构建产物
• query：分析指定的目标依赖或被依赖的目标
• dump：打印指定目标的内部信息

7.2 构建目标模式

子命令需要指定一个或多个构建目标参数，称为目标模式(target pattern)，支持以下语法：

• path:name：path目录下名为name的目标
• :name：当前目录下名为name的目标
• path:*或path：path目录下的所有目标，不包括子目录
• path/...：path目录及其子目录下的所有目标

如果path以//开头则表示从项目根目录开始的路径，否则表示基于当前目录的相对路径。

如果没有指定目标则表示当前目录下的所有目标，不包括子目录。

7.3 示例

# 构建当前目录下的所有目标，不包括子目录
blade build

# 构建当前目录及其子目录下的所有目标
blade build ...

# 构建当前目录下名为hello的目标
blade build :hello

# 构建项目根目录/common/string目录下名为string的目标
blade build //common/string:string

# 构建当前目录/string目录下名为string的目标
blade build string:string

# 构建项目根目录/common及其子目录下的所有目标
blade build //common/...

8.测试

官方文档：https://github.com/chen3feng/blade-build/blob/master/doc/en/test.md

TODO 链接GoogleTest博客

Gulp 与 npm scripts

• Gulp 与 npm scripts 都能够实现自动化构建
• Gulp 语法简单
• Gulp 语法就是 JavaScript 语法
• npm scripts 语法接近 shell 脚本 • Gulp 生态完善，构建效率高

Gulp - 基本使用

• 全局安装 gulp 客户端( npm install -g gulp- cli )
• 初始化项目(npm init --yes)
• 安装 gulp 包( npm install gulp -D )
• 新建 gulpfile 文件 ( gulpfile.js )
• 在 gulpfile.js 中，创建 gulp 任务
• 执行 gulp 任务 ( gulp

Gulp - 组合任务

Gulp - 文件操作

Gulp 是基于 流 的构建系统

Gulp 构建样式文件

Gulp 构建脚本文件

Gulp 构建脚本文件所需插件

Gulp 构建页面文件

Gulp 构建任务组合

Gulp 文件清除

Gulp 开发服务器

Gulp 使用Bootstrap

Gulp 开发服务器中监视文件变化

Gulp 在 Yeoman 中的应用-Webapp 生成器

1.什么是构建工具

比如我们执行一些例如CoffeeScript/ES6 去代替 Javascript、JS或CSS压缩、用Less去写CSS、用Jade去写HTML、用Browserify去模块化、为非覆盖式部署的资源加MD5戳等，这些操作如果我们一遍遍手动执行，非常耗费时间和精力，所以前端构建工具，或者较前端自动化构建工具，就是用来让我们不再做机械重复的事情，解放我们的双手的。

以gulp为例，编写gulpfile.js

例如：

gulp = require('gulp')
coffee = require('gulp-coffee')
uglify = require('gulp-uglify')
rename = require('gulp-rename')

file = './src/js/a.coffee'

gulp.task('coffe',function(){

	gulp.src(file)
		.pipe(coffee())   //编译
		.pipe(uglify())	 //压缩
		.pipe(rename({
			extname:".min.js"    //重命名
		}))
		.pipe(gulp.dest('./build/js'))
})

gulp.task('watch',function(
	gulp.watch(file,['coffee'])
))

gulp.task('default',['coffee'])

这样，我只要执行一下 gulp watch，它就可以自动监视 a.coffee 的变化，每次修改 a.coffee 并保存后，它就会自动执行编译->压缩丑化->重命名这一系列动作了。

参考文章：https://www.zhihu.com/question/35595198

2.构建工具的发展

构建其实是工程化、自动化思想在前端开发中的体现，将一系列流程用代码去实现，让代码自动化地执行这一系列复杂的流程。

构建可以实现如下内容：

• 代码转换：将 TypeScript/es6 编译成JavaScript、将 SCSS 编译成 CSS等。
• 文件优化：压缩JavaScript、CSS、HTML 代码，压缩合并图片等。
• 代码分割：提取多个页面的公共代码，提取首屏不需要执行部分代码让其异步记在。
• 模块合并：在采用模块化的项目里会有很多个模块和文件，需要通过构建功能将模块分类合并成一个文件。
• 自动刷新：监听本地源代码变化，自动重新构建、刷新浏览器。
• 代码校验：在代码被提交到仓库前需要校验代码是否符合规范，以及单元测试是否通过。
• 自动发布：更新代码后，自动构建出线上发布代码并传输给发布系统。

构建工具发展：Npm Scripts、Grunt、Gulp、FIS 3、Webpack、Rollup、Parcel

Grunt：

Grunt 的优点是：

• 灵活，它只负责执行我们定义好的任务；
• 大量可复用插件封装好了常见的构建任务。

Grunt 的缺点是集成度不高，要写很多配置后才可以用，无法做到开箱即用。

Grunt 相当于进化版的 Npm scripts，它的诞生其实是为了弥补 Npm Scripts 的不足。

Gulp：

Gulp 是一个基于流的自动化构建工具。除了可以管理任务和执行任务，还支持监听文件、读写文件。Gulp 被设计的非常简单，只通过下面5个方法就可以支持几乎所有构建场景：

• 通过 gulp.task 注册一个任务；
• 通过 gulp.run 执行任务；
• 通过 gulp.watch 监听文件变化；
• 通过 gulp.src 读取文件；
• 通过 gulp.dest 写完文件。

// 引入 Gulp
var gulp = require("gulp");
// 引入插件
var jshint = require("gulp-jshint");
var sass = require("gulp-sass");
var concat = require("gulp-concat");
....
// 便宜SCSS任务
gulp.task('scss', function() {
    // 读取文件，通过管道喂给插件
    gulp.src('./scss/*.scss')
        // SCSS 插件将 scss 文件编译成 css
        .pipe(sass())
        // 输出文件
        .pipe(guilp.dest('./css'));
});
// 合并压缩 JavaScript 文件
gulp.task('scripts', function() {
    gulp.src('./js/*.js')
        .pipe(concat('all.js'))
        .pipe(uglify())
        .pipe(gulp.dest('./dest'));
});
// 监听文件变化
gulp.task('watch', function() {
    // 当 SCSS 文件被编辑时执行 SCSS 任务
    gulp.watch('./scss/*.scss', ['sass']);
    gulp.watch('./js/*.js', ['scripts']);
});

Gulp 的优点：好用又不失灵活，既可以单独完成构建，也可以和其他工具搭配使用。

缺点：和Grunt 类似。集成度不高，要写很多配置后才可以用，无法做到开箱即用。

可以将Gulp 看做是 Grunt 的加强版。相对于 Grunt ，Gulp 增加了文件监听、读写文件、流式处理的功能。

FIS 3：

Fis3是一个来自百度的优秀国产构建工具。相对于 Grunt、Gulp 这些只提供了基本功能的工具。Fis3集成了开发者常用的构建功能，如下所述。

• 读写文件：通过 fis.match 读文件，release 配置文件输出路径。
• 资源定位：解析文件之间的依赖关系和文件位置。
• 文件指纹：在通过 useHash 配置输出文件时为文件 URL加上 md5 戳，来优化浏览器的缓存。
• 文件编译：通过 parser 配置文件解析器做文件转换，例如将 ES6 编译成 ES5。
• 压缩资源：通过 optimizer 配置代码压缩方法。
• 图片合并：通过 spriter 配置合并 CSS 里导入的图片到一个文件中，来减少 HTTP 请求数。

大致使用如下：

// 加 md5
fis.match('*.{js,css,png}', {
    useHash: true
});
// 通过fis3-parse-typescript插件可将 TypeScript 文件转换成 JavaScript 文件
fis.match('*.ts', {
    parser: fis.plugin('typescript')
});
// 对CSS进行雪碧图合并
fis.match('*.css', {
    // 为匹配到的文件分配属性 useSprite
    useSprite: true
});
// 压缩 JavaScript
fis.match('*.js', {
    optimizer: fis.plugin('uglify-js')
});
// 压缩CSS
fis.match('*.css', {
    optimizer: fis.plugin('clean-css')
});
// 压缩图片
fis.match('*.png', {
    optimizer: fis.plugin('png-compressor')
});

可以看出 Fis3 很强大，内置了许多功能，无需做太多配置就能完成大量工作。

Fis3的优点：集成了各种Web老发所需的构建功能，配置简单，开箱即用。其缺点是目前官方已经不再更新和维护，不支持最新版本的Node。

Webpack：

Webpack 是一个打包模块化的JavaScript的工具，在Webpack里一切文件皆模块，通过 loader 转换文件，通过Plugin 注入钩子，最后输出由多个模块组合成的文件。Webpack 专注于构建模块化项目。

其官网的首页图很形象的展示了 Webpack 的定义，如下图：

一切文件，如JavaScript、CSS、SCSS、图片、模板，对于Webpack 来说都是一个个模块，这样的好处是能清晰地描绘各个模块之间的依赖关系，以方便Webpack进行组合和打包，经过Webpack的处理，最终会输出浏览器能使用的静态资源。

Webpack具有很大的灵活性，能配置处理文件的方式，使用方法大致如下：

module.exports = {
    // 所有模块的入口，webpack从入口开始递归解析出所有依赖的模块
    entry: './app.js',
    output: {
        // 将入口所依赖的所有模块打包成一个文件 bundle.js 输出
        filename: 'bundle.js'
    }
}

Webpack的优点是：

• 专注于处理模块化的项目，能做到开箱即用、一步到位；
• 可通过 Plugin 扩展，完整好用又不失灵活性；
• 使用场景不局限于Web开发；
• 社区庞大活跃，经常引入紧跟时代发展的新特性，能为大多数场景找到已有的开源扩展；
• 良好的开发体验；
  Webpack的缺点是：只能用于采用模块化开发的项目。

Rollup：

Rollup 是一个和 Webpack 很类似但专注于ES6的模块打包工具。它的亮点在于，针对ES6源码进行 Tree Shaking,以去除那些已经被定义但没被使用的代码并进行 Scope Hoisting，以减少输出文件的大小和提升运行性能。然而 Rollup 的这些亮点随后就被 Webpack 模仿和实现了。

Parcel：

Parcel 是 最近新起的Web 应用打包工具，适用于经验不同的开发者。它利用多核处理提供了极快的速度，并且不需要任何配置。

Parcel的优点：

• 极速打包。Parcel 使用 worker 进程去启用多核编译。同时有文件系统缓存，即使在重启构建后也能快速再编译。
• 开箱即用。对 JS, CSS, HTML, 文件 及更多的支持，而且不需要插件。
• 自动转换。如若有需要，Babel, PostCSS, 和PostHTML甚至 node_modules 包会被用于自动转换代码。
  -热模块替换。Parcel 无需配置，在开发环境的时候会自动在浏览器内随着你的代码更改而去更新模块。
  友好的错误日志。当遇到错误时，Parcel 会输出 语法高亮的代码片段，帮助你定位问题。

缺点：

• 不支持SourceMap：在开发模式下，Parcel也不会输出SourceMap，目前只能去调试可读性极低的代码；
• 不支持剔除无效代码(TreeShaking)：很多时候我们只用到了库中的一个函数，结果Parcel把整个库都打包了进来；
• 一些依赖会让Parcel出错：当你的项目依赖了一些Npm上的模块时，有些Npm模块会让Parcel运行错误；
• Parcel需要为零配置付出代价。零配置其实是把各种常见的场景做为默认值来实现的，

这虽然能节省很多工作量，快速上手，但这同时会带来一些问题：

• 不守规矩的node_module：有些依赖的库在发布到Npm上时可能不小心把.babelrcpostcss.config.js tsconfig.json这些配置文件也一起发布上去了，
• 不灵活的配置：零配置的Parcel关闭了很多配置项，在一些需要的配置的场景下无法改变。

Parcel使用场景受限。目前Parcel只能用来构建用于运行在浏览器中的网页，这也是他的出发点和专注点。在软件行业不可能存在即使用简单又可以适应各种场景的方案，就算所谓的人工智能也许能解决这个问题，但人工智能不能保证100%的正确性。

反观Webpack除了用于构建网页，还可以做：

• 打包发布到Npm上的库
• 构建Node.js应用(同构应用)
• 构建Electron应用
• 构建离线应用(ServiceWorkers)

Parcel与Webpack的对比：http://www.cnblogs.com/lxg0/p/8387670.html

3.为什么选择Webpack

上面介绍的构建工具是按照他们的诞生时间排序的，他们是时代的产物，侧面反映出 Web 开发的发展趋势，如下所述：

• 在 Npm Scripts 和 Grunt 时代，Web 开发要做的事情变多，流程复杂，自动化思想被引入，用于简化流程；
• 在 Gulp 时代，开始出现一些新语言用于提高开发效率，流程处理思想的出现是为了简化文件转换的流程，例如将ES6转换为ES5；
• 在Webpack时代，由于单页应用的流行，网页的功能和实现代码变的复杂、庞大，Web开发向模块化改进。

这些构建工具都有各自的定位和专注点，它们之间既可以单独完成任务，也可以互相搭配起来弥补各自的不足。在了解这些常见的构建工具后，我们需要根据自己的需求去判断应该如何进行选择和搭配它们才能更好的满足自己的需求。

经过多年的额发展，Webpack 已经成为构建工具中的首选，这是因为：

• 大多数团队在开发新项目时会采用紧跟时代的技术，这些技术几乎都会采用“模块化+新语言+新框架”，Webpack可以为这些新项目提供一站式的解决方案；
• Webpack有良好的生态和维护团队，能提供良好的开发体验并保证质量；
• Webpack 被全世界大量的Web开发者使用和验证，能找到各个层面所需要的教程和经验分享。

4.Gulp和Webpack的区别

常有人拿gulp与webpack来比较，知道这两个构建工具功能上有重叠的地方，可单用，也可一起用，但本质的区别就没有那么清晰。

Gulp强调的是前端开发的工作流程，我们可以通过配置一系列的task，定义task处理的事务（例如文件压缩合并、雪碧图、启动server、版本控制等），然后定义执行顺序，来让gulp执行这些task，从而构建项目的整个前端开发流程。 简单说就一个Task Runner，就是用来跑一个一个任务的。

Gulp 没发解决的是 js module 的问题，是你写代码时候如何组织代码结构的问题。

Webpack是一个前端模块化方案，更侧重模块打包，我们可以把开发中的所有资源（图片、js文件、css文件等）都看成模块，通过loader（加载器）和plugins（插件）对资源进行处理，打包成符合生产环境部署的前端资源。

相同点：文件合并与压缩（css,js），sass/less预编译，启动server，版本控制。

不同点，虽然都是前端自动化构建工具，但看他们的定位就知道不是对等的。

• gulp严格上讲，模块化不是他强调的东西，他旨在规范前端开发流程。
• webpack更是明显强调模块化开发，而那些文件压缩合并、预处理等功能，不过是他附带的功能。

参考文章：

https://blog.dunizb.com/2018/04/23/前端构建工具发展及其比较/?utm_medium=hao.caibaojian.com&utm_source=hao.caibaojian.com#Parcel

https://juejin.im/entry/5ae5c8c9f265da0b9f400d8e

https://www.cnblogs.com/iovec/p/7921177.html

支付宝前端构建工具的发展和未来的选择：https://github.com/pigcan/blog/issues/4

5.为什么node出现之后，各种前端构建工具和手段才如雨后春笋般层出不穷

https://www.zhihu.com/question/35427358

6.browserify

服务器端NodeJS自带模块功能，可以使用require和module.exports构建项目

随着项目的增大，浏览器端任务越来越重，依赖关系越来越复杂，需要使用工具实现模块化。

Browserify通过require和module.exports来导入和导出。

Browserify的原理：部署时处理代码依赖，将模块打包为一个文件。

参考文章：

https://blog.csdn.net/real_bird/article/details/53560206?utm_source=copy

https://www.cnblogs.com/xiaohuochai/p/6850977.html#anchor2