最近我的前端开发离不开SASS、LESS等工具，多人协作项目中也会引入Lint和Test。前端文件需要在上线前运行这些任务。先来说说前端构建工具。目前前端构建工具非常丰富。它们大致可以分为几类： 1。任务运行器（taskrunner） 通过声明和组合构建任务来构建整个网站。一套任务声明语法和任务实现接口。比如Grunt和Gulp，都是插件式架构。有大量的插件可用，缺点是你只能用插件来做所有事情，如果你没有，你可以自己写一个。 在任务管理工具中，我们可以声明几个任务，比如压缩、测试、替换等，这些任务可以相互依赖（常用于定义顺序），可以是同步的，也可以是异步的。然后我们可以自由选择运行哪个任务，任务管理工具会帮我们运行它（以及它的依赖）。 工作的第一年，我使用Grunt来构建和部署整个网站。tmyGrunt的问题在于一切都依赖于插件，而插件不一定能很好地协同工作。这段时间我们写了几百行构建脚本，引入了大量的插件。维护Gruntfile是我们最头疼的问题之一。 我已经迁移到Gulp，脚本已经减少到几十行，Gulp是一个优秀的构建工具。Gulp也是一个具有插件架构的任务管理工具。与Grunt最大的不同在于它采用了流式接口，减少了代码量，插件对接流畅。 然而，与Grunt一样，Gulp也有JavaScript任务管理工具的缺点。每个JS工具库都需要打包成Gulp插件才能使用，不能选择自己喜欢的版本或者自己喜欢的小众工具。同时，Gulp比Grunt更难调试：很难将console.log插入到基于Stream的构建过程中。 2。打包工具（packagetool） 通过为每一类文件配置所需的处理方式来实现整个站点的构建。像Webpack和FIS一样，它们都是针对整个站点的整体构建解决方案。 Webpack提供了一个集成的构建方案。我们不需要关心构建过程的实现细节，只需要设置每个文件应该经过哪些预处理和转换，并给出打包地址即可。Webpack甚至会自动替换HTML中的相应资源。 打包工具也有比较陡峭的学习曲线，而且这些工具都相当强大。劣势也很明显：很难精确定义构建过程，所以和AMD混用会出现很多坑。如果你有像哈特尔这样的洁癖，你一定不能容忍这种简陋的工具。哈特尔仍然相信他可以清楚地定义依赖关系。 3。构建工具（buildtool） 关于构建工具Harttle只想提一下make。Make不仅仅是目标+依赖项+命令！ Make是一个自解析工具，可以解析任意树依赖，并根据文件修改时间智能更新。由于Make直接使用了Bash，Unix强大的工具库只用STDIN和STDOUT就可以解决大部分的文件处理问题。 构建工具的优势在于可以直接调用JS工具的CLI接口，无需打包即可自由选择任何JS工具。缺点是没有为Web前端提供更多的构建功能。 前端的具体搭建要求是什么？接下来说一下具体步骤。 1。预处理 JS/CSS/HTML在设计之初没想到这么流行，整个Web已经形成了一个庞大的分布式文档。由于兼容性问题，低级语言的替换或升级面临很大困难。这催生了各种中间语言预处理器，如SASS、LESS、CoffeeScript、Babel等。 这些预处理工具将我们的中间代码转换为可运行的JavaScript。这些预处理器允许我们预先使用ECMAScript6，以结构化的方式编写CSS，或者在CommonJS环境中编写JavaScript等。 2。样式和测试 在典型的工作流程中，每个Pushmaster分支或npm发布都应首先运行代码样式检查和单元测试。我们需要在适当的时候自动执行这些操作。 3。资源压缩 在开发网站代码时，我们希望以模块化的方式进行编码。每个业务逻辑、公共实用程序或架构元素都需要组织在一个单独的文件中。但是如果用户在浏览网页时加载了这么多的源文件，那么页面打开速度就会大大降低。 因此网站发布时需要合并压缩源代码，JavaScript可能也需要模块化（AMD，CommonJS等），CSS文件可能也需要合并，兼容性前缀（-webkit-,-moz-)等等。我们还想编写这些重复性任务的脚本。 4。静态资源替换 最复杂的构建需求是静态资源的URL替换。因为生产环境的资源地址可能和开发环境的资源地址相差很大，可能是JS合并，CSS合并，或者是应用了CDN加速。我们需要在部署时更改所有HTML文件中的静态资源地址。
