自动化构建是前端工程化当中非常重要的组成部分，自动化的概念就是通过机器代替手工完成一些工作，构建可以理解为转换。前端行业的自动化构建，就是把开发阶段写出来的源代码自动化的去转换成生产环境当中可以运行的代码或者程序。一般会把这个转换过程称之为自动化构建工作流，它的作用就是让开发者尽可能的脱离运行环境中的种种问题。去在开发阶段去使用一些提高效率的语法规范和标准，最典型的应用场景就是开发者在去开发网页应用时，就可以使用ES的最新标准去提高编码效率和质量、利用sass去增强css的可编程性、然后借助模版引擎去抽象页面当中重复的html。这些用法在浏览器当中没有办法被直接支持的，这种情况下去自动化构建工具就可以派上用场。通过自动化构建的方式将这些不被支持的代码特性，转换成能够直接运行的代码。这样我们就可以直接在开发过程中，通过这些方式去提高编码效率。
比如在一个案例中一开始使用的是直接编写css方式去完成网页的样式，如果想通过sass去增强css的编程性。具体的实现方式就是在开发时添加一个构建的环节，这样就可以让我们在开发环节就可以通过sass编写样式，在通过工具将sass去构建为css。在项目中新建一个sass文件，在这个sass文件当中就可以按照 sass 的语法去编写我们的网页样式。相对于css，sass的编程能力更强，但是sass并不能在浏览器环境当中直接去使用。所以说我们需要去在开发阶段通过一个工具去把它转换成css，这里使用的是sass官方提供的sass模块。在命令行通过 yarn add sass --dev 将sass作为一个开发依赖安装到开发项目中来，安装完成之后在node_modules 就会出现一个 .bin 的目录。在这个目录下就有一个 sass 的命令文件，在命令行当中就可以通过路径找到这个命令 .\node_modules\.bin\sass 它会打印出来一些帮助信息。在这个帮助信息的一开始就给出来了这个命令的具体用法，具体的就是我们需要指定一个sass的输入路径以及一个css 的输出路径。.\node_modules\.bin\sass scss/main.scss css/style.css 再次执行就可以自动的去帮我们把我们的sass文件转换成css，不仅如此它还帮我们添加了对应的source map 文件，这样的话我们就可以在调试阶段，定位到我们源代码当中的位置。但是这样也有一个比较麻烦的地方，那就是每次都需要重复的去输入这些复杂的命令，而且在别人接手你的项目过后，他也不知道如何去运行这些构建的任务。所以说需要去做一些额外的事情去解决这些在项目开发阶段重复去执行的命令，npm scripts 主要就是用来解决这个问题的。可以在npm scripts 当中去定义一些与这个项目开发过程有关的脚本命令，这样一来就可以让这些命令跟着项目一起去维护便于我们在后期开发过程中使用。所以说，这里最好的方式就是通过 npm scripts 的方式去包装项目中的构建命令。具体的实现方式就是在package.json当中去添加一个scripts字段，这个字段是一个对象。键就是script的名称，值就是我们需要去执行的命令。这里需要注意的是script它可以自动去发现node_modules里面的命令，所以说就不需要写完整的路径，直接使用命令的名称就可以了。
"scripts" : {
"build" : "sass scss/main.scss css/style.css"
}
完成过后，就可以通过 npm run build 或者 yarn build 启动这个命令。另外 npm scripts 也是实现自动化构建工作流的最简单的方式，接下来再看一下如何通过它去实现自动化构建。这里为项目在去安装一个叫做 browser-sync 的模块，用于去启动一个测试服务器去运行项目。
"scripts" : {
"build" : "sass scss/main.scss css/style.css",
"serve": "browser-sync ."
}
如果说在browser-sync 工作之前并没有生成样式，此时browser-sync工作的时候页面就没样式文件。这里就需要在启动serve命令之前去让build任务去工作，所以这里可以借助于npm scripts 的钩子机制，去定义一个preserve它会自动在sever命令执行之前去执行。
"scripts" : {
"build" : "sass scss/main.scss css/style.css",
"serve": "browser-sync .",
"preserve" : "yarn build"
}
光有这些还不够，还可以为sass命名添加一个--watch的参数，有了这个参数过后sass在工作时就会监听文件的变化，一旦当代码当中的sass文件发生改变时就会自动被编译。
"scripts" : {
"build" : "sass scss/main.scss css/style.css --watch",
"serve": "browser-sync .",
"preserve" : "yarn build"
}
这时候在命令行重新执行这个命令，sass命令在工作时命令行会阻塞在这里去等待文件的变化。这样就导致了后面的browser-sync并没有办法直接去工作，这种情况下就需要同时去执行多个任务。这里可以借助于npm-run-all 这个模块去实现：
"scripts" : {
"build" : "sass scss/main.scss css/style.css --watch",
"serve": "browser-sync .",
"start" : "run-p build serve"
}
最后我们也可以对 browser-sync 这个命令去添加一个 --files 的参数，这个参数可以让browser-sync在启动过后去监听项目下的文件的变化。一旦当文件发生变化过后，browser-sync会将这些文件的内容自动同步到浏览器，从而更新浏览器当中的界面。
"scripts" : {
"build" : "sass scss/main.scss css/style.css --watch",
"serve": "browser-sync . --files\"css/*.css\"",
"start" : "run-p build serve"
}
npm scripts 确实能解决一部分的自动化构建任务，但是对于相对复杂的构建过程npm scripts就显得非常吃力。这时就需要更为专业的构建工具，比如 gulp、grunt和fis。webpack严格来说是一个模块打包工具。这些工具都可以帮助开发者解决重复无聊的工作，从而实现自动化用法上也都大体相同。都是先通过一些简单的代码去组织一些插件的使用，然后就可以使用这些工具去执行各种各样的重复的工作。grunt 是最早的前端构建工具，插件生态非常完善。用官方的话说，它可以帮开发者完成一切自动化的工做。但是它的工作过程是基于临时文件实现的，所以说它的构建速度相对较慢，它的每一步都会有磁盘读写操作。比如，在sass文件编译完成过后它就会将结果写入到一个临时的文件。然后下一个插件它在去读取这个零时文件，进行下一步的处理。这样一来，处理的环节越多文件读写的次数也就越多。对于超大型项目当中我们的项目文件会非常的多，构架速度就会特别的慢。gulp很好的解决了 grunt 当中构建速度非常慢的问题，因为它是基于内存去实现的，也就是说它对文件的处理环节都是在内存当中完成的。相对于磁盘读写速度自然就会快很多，另外它默认支持同时去执行多个任务效率自然大大提高。而且它的使用方式写对于grunt更加直观易懂，插件生态也同样非常完善。
