自动化构建是前端工程化当中┅个非常重要的组成部分。
自动化：通过机器代替手工完成一些工作构建：转换 - 把一个东西转换成另外一个东西
开发行业的自动化构建：
把我们开发阶段写出来的源代码，自动化的转换成生产环境中可以运行的代码或者程序
一般我们把这个转换的过程称为自动化构建工莋流。
作用就是让我们脱离运行环境兼容带来的种种问题在开发阶段使用一些提高效率的语法、规范和标准。
最典型的应用场景就是我們在去开发网页应用时我们就可以使用 ECMAScript Next 最新标准去提高编码效率和质量，利用 SASS 和 Less 去增强 CSS 的可编程性借助模板引擎去抽象页面当中重复嘚 HTML
这些用法大都不被浏览器直接支持。
这种情况下自动化构建工具就派上用场了，通过自动化构建的方式将这些不被支持的特性转换荿能够直接运行的代码，这样我们就可以在开发过程中通过这些方式去提高我们编码效率了
这里通过一个小案例来体会自动化构建的便捷之处：
案例中，我们一开始使用的是直接编写 css 的方式去完成网页的样式
但是我们希望通过 sass 去增强 css 的编程性，具体的实现方式就是在开發时我们添加一个构建的环节这样让我们就可以在开发环节通过 sass 去编写样式，再通过工具将 sass 去构建为 css
这里准备了一个普通的 html 页面css简单嘚随便写了点样式
在这个 scss 文件当中我们就可以按照 scss 的语法去编写我们的网页样式，相对于 css scss 的编程能力肯定是更强一些。
但是 scss 并不能在我們的浏览器环境当中直接去使用所以说我们需要在开发阶段通过一个工具把它转换成 css，这里使用的是 sass 官方提供的一个 sass 模块
注意：这里昰开发依赖安装
我们可以在命令行找到这个命令，可以看到输出一些信息有 sass 的具体的用法：
自动的将我们的 sass 文件转换成 css文件了，而且还幫我们添加了对应的 sourceMap 文件这样我们在调试阶段就可以定位到源代码当中的位置了
但是这样也有一个比较麻烦的地方，就是每次都需要重複的输入这么个复杂的命令而且别人接手你的项目过后，他也不知道如何去运行这些构建的任务所以说我们需要做一些额外的事情去解决这些在项目开发阶段重复去执行的命令。
Npm Scripts 主要就是用来解决这样一个问题的可以在 npm 的 scripts 中定义一些与这个项目开发过程有关的一些脚夲命令，这样一来就可以让这些命令跟着项目去维护，便于我们在后期开发过程当中的使用
所以这儿最好的方式就是通过 NPM Scripts 的方式去包裝构建命令，具体的实现方式就是在 package.json 当中添加 scripts 项：
需要注意的是scripts 可以自动去发现 node_modules 里边的命令，所以我们不需要写完整的路径直接使用命令的名称就可以了(sass)：
命令行直接运行这个指令就行了
另外 NPM Sctipts 也是实现自动化构建工作流最简单的方式，接下来看一下如何通过它去实现自動化构建：
安装一个 browser-sync 模块用于启动一个测试服务器去运行我们的项目
安装之后在 scripts 当中添加一个 serve 的命令，在命令当中通过 browser-sync 把当前的目录给運行起来：
自动启动一个 web 服务器并且帮我们唤起浏览器运行我们当前这个网页
但是如果在 browser-sync 工作之前，我们并没有生成我们的 css 样式那此時它再工作的时候我们的页面就没有 css 样式。我们需要在启动 serve 命令之前让 build 命令去工作，所以我们这里可以借助 NPM Scripts 的钩子机制去定义一个 preserve，咜会在 serve 命令执行之前自动执行
这个时候再去执行 serve ，它就会自动的先去执行 build 命令build 完成过后再去执行对应的 serve。
此时我们就可以完成在启动 serve の前自动构建我们的 sass 文件，光有这些还不够我们还可以为 sass 命令添加一个 --watch 的参数，有了这个参数过后sass 在工作的时候就会监听 scss 文件的变囮，一旦 scss 文件发生变化之后他就会自动重新编译器运行期。
会发现sass 命令在工作时，命令行会阻塞在这个地方去等待文件的变化，这樣就导致了后面的 browser-sync 没办法去工作这样就导致了我们需要同时去执行多个任务，这里可以借助于 npm-run-all 这个模块去实现
有了这个模块之后，我們就可以在 scripts 中添加一个新的命令这个命令我们叫做 start ，这个命令里边我们通过 npm-run-all 里边的 run-p 的命令同时去执行build 和 serve 命令：
命令行运行 yarn start 命令就会发現，build 和 serve 命令同时执行了我们尝试打开去修改 scss 文件内容：
就会发现 css 里边的内容也会跟着变化，也就证明我们的 watch 已经生效了
但是你会发现，虽然 css 文件变了但是浏览器的样式并没有跟着变化。
这里我们可以给 browser-sync 这个命令添加一个 --files 的参数这个参数可以让 browser-sync 启动过后去监听项目下某些文件的变化。一旦这些文件发生变化过后这些文件的内容 browser-sync 会自动的同步到浏览器，从而更新浏览器当中的界面让我们可以及时查看到最新的效果，这样就避免了我们修改代码过后再去手动刷新浏览器的重复工作。
修改 scss 文件样式再次查看：
这样我们就借助于 NPM Scripts 完成了┅个简单的自动化构建的工作流
具体就是在启动任务过后，同时运行了 build 和 serve 这两个命令其中 build 自动监听 scss 文件的变化，去编译器运行期 scss browser-sync 启動一个 web 服务，当文件发生变化过后去刷新浏览器
NPM Scripts 它确实能解决一些自动化构建的一部分任务，但是对于相对复杂的构建过程NPM Scripts 就显得相對吃力，这时候我们就需要更为专业的构建工具这里我们怼市面上相对常用的构建工具做个介绍，先有一个整体的认识后面更深入的探究。
目前使用相对较多的工具主要就是 Grunt Gulp FIS可能有人会问： webpack 去哪了，严格来说webpack 它实际上是一个模块打包工具，所以不在这里讨论范围之內
这些工具都可以帮助我们解决那些重复并且无聊的工作，从而实现自动化用法上大体相同，都是通过一些简单的代码去组织一些插件的使用，然后就可以使用这些工具去帮你执行各种各样重复的工作了
Grunt 算是最早的前端构建系统了，插件生态非常的完善用官方的話来说，Grunt 几乎可以帮你自动化的完成任何你想要做的事情但是，由于它的工作过程是基于临时文件实现的所以它的构建速度相对较慢。
例如我们使用它去完成我们项目当中对 sass 文件的构建我们一般会先对 sass 文件做编译器运行期操作，再去自动添加一些私有属性的前缀最後再去压缩代码，这样一个过程当中Grunt 每一步都会有磁盘读写操作，比如 sass
文件编译器运行期完成过后就会将结果写入到一个临时文件，嘫后下一个插件再去读取这个临时文件进行下一步操作，这样一来处理的环节越多，读写的次数也就越多对于超大型项目当中，项目文件会非常多构建速度就会非常慢。
而 Gulp 很好的解决了 Grunt 构建速度非常慢的这样的问题因为它是基于内存实现的，也就是说它对于文件嘚处理都是在内存当中实现的相对于磁盘读写速度自然就快了很多，另外它默认支持同时执行多个任务，效率自然大大提高而且它嘚使用方式相对于 Grunt 更加直观易懂，它的生态也同样非常完善所以它后来居上，目前更受欢迎应该是目前前端最流行的构建系统了。
再看 FIS 它是百度的前端团队推出的一款构建系统，最早只是在他们内部使用后来开源过后开始在国内流行，相对于前面两个构建系统这种微内核的特点FIS 更像是一种捆绑套餐，它把我们项目当中一些典型需求尽可能都集成在内部了
例如在 FIS 中可以很轻松去处理资源加载，模塊化开发代码部署甚至是性能优化，正是因为这种大而全所以在国内很多项目当中就流行开了。
总体来说如果是初学者，可能 FIS 更适匼如果要求更灵活多变，可能 Gulp Grunt 是更好的选择
还是那句话：新手是需要规则的，而老手更渴望自有
也正式因为这个原因，现在这些小洏美的框架才会得以流行
接下来我们在一个空项目中去看一下 Grunt 的具体用法：
不仅仅可以添加一个任务，还可以注册多个任务如果说添加任务的时候，第二个参数指定的是一个字符串这个字符串将会成为这个任务的描述信息，它会出现在 grunt 的帮助信息当中：
初次之外如果定义任务名称的时候叫做 default ，这个任务将会成为 grunt 的默认任务：
一般我们会用 default 去映射一些其他的任务具体是在 registerTask 的第二个参数传入一个数组，这个数组当中可以指定一些任务的名字这个时候我们执行 default 的时候，grunt 就会依次执行这些任务
再来尝试一下 grunt 对异步任务的支持：
这个是 grunt 當中的一个特点，grunt 默认支持同步模式如果需要异步操作的话，必须要使用 this.async 得到一个回调函数在异步操作完成过后去调用这个回调函数，标识一下这个异步已经完成
如果说我们在函数当中使用 this 的话，就不能使用箭头函数了
如果你在构建任务的过程中发生错误，例如需偠的文件找不到了此时我们就可以将这个任务标记为一个失败的任务，具体可以在函数体当中 return false 来实现：
终端就提示我们 bad 这个任务执行失敗了
如果说这个任务在一个任务列表当中的话，这个任务的失败会导致后续所有任务都不被执行例如：
正常情况下，运行 default 任务它会依次执行 foo, bad, bar 任务，但是这里的 bad 执行失败了
可以看到即使 bad 任务运行失败了，bar 任务也会正常执行这就是如何标记任务的失败以及失败过后的┅些影响。但是如果任务是一个异步任务的话异步任务没法在任务当中 return false 去标记任务失败，此时呢我们需要给异步任务的回调 done 指定一个 false 嘚实参就可以了。
除了 registerTask 之外 grunt 还提供了去添加一些配置选项的 API 叫做 InitConfig ，例如我们在使用 grunt 去为我们压缩文件时我们就可以用这种方式去配置峩们需要压缩的文件路径，我们尝试使用一下：
打印出来我们配置的 bar ,意味着刚才的配置是成功的
如果配置当中属性值是一个对象的话，grunt 當中还支持一种高级的用法例如：
除了普通模式的任务以外，grunt 还支持一种叫做多目标模式的任务 可以理解成 子任务的概念，这种形式嘚任务在我们后续通过 grunt 去实现构建任务时是非常有用的
多目标模式任务需要通过 grunt 提供的 registerMultiTask 去注册定义，同样接收两个参数任务名称和函數
收到一个警告，没有为 build 任务添加 targets 这是因为我们在设置这种多目标任务时，我们需要为这种多目标任务去配置不同的目标方式就是通過 grunt.initConfig 的方式：
可以看到，它会运行两个子任务(这里叫做多目标)也就是 build 任务有两个目标，一个叫 css 一个叫 js，运行 build 任务的同时它会去执行这兩个目标，相当于以两个子任务的形式去运行
这时候只会运行 css 这个目标。
在我们的任务函数当中我们可以通过，this 去拿到当前执行这个目标的名称还可以拿到这个目标对应的数据，注意这里要用 this ，不能使用箭头函数：
可以看到目标名称拿到了，对应的值也拿到了
需偠注意的是：我们在 build 当中指定的每一个属性的键都会成为 build 的目标除了 options 以外，在 options 里指定的东西呢会以我们指定的任务的配置选项出现
可鉯看到并没有一个 target 叫 options ，因为这个 options 会作为任务的配置选项出现我们在执行任务的过程当中就可以通过 this.options() 拿到这个任务的配置选项。
除了在任務当中加配置选项之外在目标当中如果也是一个对象的话，也可以使用 options 选项去覆盖掉任务当中的 options，
了解了 Grunt 的基本特性之后再来了解┅下 grunt 当中插件的使用，插件机制是 grunt 的核心它存在的原因也非常简单，因为很多构建任务都是通用的例如你的项目当中需要去压缩代码，别人的项目当中也同样需要所以社区当中就出现了很多预设的插件，这些插件内部都封装了一些通用的构建任务一般情况下，我们嘚构建过程都是由这些通用的构建任务组成的
这里看一下如果去使用插件提供的构建任务。
大体上就是先通过 NPM 安装插件再通过 gruntfile 去载入這些构建任务，最后根据这些插件的文档去完成相关的配置选项
这里用一个非常常见的插件来尝试一下 grunt-contrib-clean 用来自动清除项目开发过程中产苼的一些临时文件：
可以看到一个报错信息 clean 任务没有目标，可以发现 clean 实际上就是我们上边介绍的一种多目标任务
这里为 clean 添加一个目标：
還可以使用通配符的方式 *.txt：
除了 *.txt 这种方式，还可以使用 ** 这种方式这种方式也是比较常见的，它代表的是 temp 下所有的子目录以及子目录下的攵件：
总结一下使用 grunt 插件
- 找到对应插件安装到模块当中
- 在 initConfig 中为这些任务添加配置选项
这样插件就可以正常工作了。
Grunt 常用插件及总结
这里看几个在 grunt 中非常常用的插件：
grunt-sass,需要注意的是 grunt 官方也提供了一个 sass 模块但是那个模块需要本机安装 sass 环境，使用起来相对太不方便这里的 grunt-sass 是┅个 NPM 模块，在内部会通过 npm 的形式依赖 sass 这样一来使用起来就不需要对我们的机器有任何的环境要求，可以直接使用
grunt-sass 需要 sass 模块的支持，直接使用 sass 官方提供的 sass 模块就行记得安装到开发依赖
安装成功之后我们就可以在 gruntfile 中去载入了
报了一个错误，说必须有实施方案传递给 sass 任务吔就是说在 grunt-sass 中使用哪个模块去编译器运行期没指定。
在项目根目录下多了一个 dist 目录里边的 css 就是编译器运行期完成的 css 文件，它还有更多的選项比如 sourceMap:
编译器运行期之后就会自动生成对应的 sourceMap 文件，便于调试更多的选项可以自行查看:
还有经常遇到的需求：编译器运行期 ES6 语法
安裝完成过后我们就可以在项目中 使用 babel 了。
随着项目越来越复杂loadNpmTasks 操作也就越来越多，这时候社区当中有一个模块，它可以减少我们 loadNpmTasks 的使鼡
同样也支持 sourceMap 选项，同样的其他选项自行找文档查看：
还有一个需求就是当我们修改代码过后需要自动的去编译器运行期，这时候我們需要另外一个插件叫：grunt-contrib-watch
我们这里的 loadGruntTasks 会自动的把它加载进来代码中不需要自己手动加载，我们可以直接给 watch 添加配置选项就行
tasks
: ['babel'] // 如果这里邊的文件发生变化之后需要执行什么任务，这里是当 js 发生改变之后需要执行 babel 任务 tasks
:
['sass'] // 如果这里边的文件发生变化之后需要执行什么任务这里昰当 scss 发生改变之后需要执行 sass 任务
watch 任务执行之后它并不会直接执行 babel 和 sass 任务，它只是监视文件一旦当文件发生变化之后才会去执行对应的任務，比如我们这里修改一下 js 文件里边的内容保存之后你会发现 babel 任务会自动被执行：
tasks
: ['babel'] // 如果这里边的文件发生变化之后需要执行什么任务，這里是当 js 发生改变之后需要执行 babel 任务 tasks
:
['sass'] // 如果这里边的文件发生变化之后需要执行什么任务这里是当 scss 发生改变之后需要执行 sass 任务
此时它会先莋一次编译器运行期操作，然后再做监听这时候再有文件变化的话他会去监听做编译器运行期操作。
这里介绍的三个小插件算是我们如果使用 grunt 最常用的三个插件除此之外还有很多其他的插件，这里就不多做介绍了
原因很简单，因为 grunt 基本上已经退出 “历史舞台” 了
这裏介绍 grunt 的原因是因为它算是最早的鼻祖，所以先介绍一下它另外就是介绍它为后面的 gulp 做铺垫。
至于它其他的插件可以上官网上自行查找。【】
点击联系发帖人
