共计 1923 个字符，预计需要花费 5 分钟才能阅读完成。
最近我的前端开发曾经离不开 SASS，LESS 等工具了，在多人合作我的项目中还会引入 Lint 和 Test。前端文件在上线前就须要运行这些工作。首先聊聊前端构建工具，目前前端构建工具曾经十分丰盛，大抵分一下类：
1、工作管理工具（task runner）
通过申明和组合构建工作来进行整个网站的构建，有本人的一套工作申明语法和工作实现接口。例如 Grunt 和 Gulp，这两个都是插件式的架构。有大量的插件可用，毛病就在于做什么都只能用插件，没有就本人写一个。
工作管理工具中咱们能够申明若干个工作，比方压缩、测试、替换等。这些工作间可相互依赖（往往用来定义程序），能够是同步的也能够是异步的。而后咱们能够自在地抉择运行哪个工作，工作管理工具会帮咱们运行它（以及它的依赖）。
工作第一年我应用的是 Grunt 构建和部署整个网站。tmy Grunt 的问题在于所有事件都依赖于插件，而插件之间不肯定可能很好地合作。在此期间咱们写了几百行的构建脚本，同时引入了大量的插件。保护 Gruntfile 是咱们最头疼的事之一。
尔后我迁徙到了 Gulp，脚本缩减为几十行，Gulp 是一个优良的构建工具。Gulp 也是插件式架构的工作管理工具，与 Grunt 最大的区别在于采取流式接口，缩小代码量的同时插件之间的连接也很顺畅。
然而像 Grunt 一样，Gulp 也有着 JavaScript 工作管理工具的毛病。每个 JS 工具库都须要包装为 Gulp 插件来应用，我无奈抉择我喜爱的版本或者我喜爱的小众工具。与此同时，Gulp 比 Grunt 还要难以调试：基于 Stream 的构建流程中很难插入一条 console.log。
2、打包工具（package tool）
通过为每一类文件配置须要的解决形式，来实现整个站点的构建。如 Webpack 和 FIS，这两个都是整个站点的整体构建解决方案。
Webpack 给出了一体化的构建计划。咱们无需关怀构建过程的实现细节，只须要为每种文件设置它应该通过哪些预处理、哪些转换，并且给定打包地址。Webpack 甚至会主动替换 HTML 中的相应资源。
打包工具的学习曲线也较为平缓，这类工具性能都相当弱小。毛病也很显著：很难准确地定义构建过程，所以和 AMD 混用时会产生十分多的坑。如果你和 Harttle 一样有着洁癖肯定不能忍这种粗犷的工具，Harttle 依然置信本人可能把依赖定义分明。
3、构建工具（build tool）
对于构建工具 Harttle 只想提 make。Make 不仅仅是指标 + 依赖 + 命令！
Make 是以来解决工具，能够解决任何树状依赖并依据文件批改工夫来智能地更新。因 Make 间接应用 Bash，Unix 弱小的工具库只需 STDIN 和 STDOUT 便能解决绝大多数文件解决问题。
构建工具的劣势在于可间接调用 JS 工具的 CLI 接口，能够自在地抉择任何 JS 工具而不需包装。毛病便是没有针对 Web 前端提供更多的构建性能。
具体前端有哪些构建需要呢，接下来将说说具体步骤。
1、预处理
JS/CSS/HTML 在设计之初并未料及它们会这样风行，整个 Web 曾经造成一个大的分布式文档。低层语言的更换或降级都因兼容性问题而面临着微小艰难。这催生了各种两头语言个预处理器，例如 SASS，LESS，CoffeeScript，Babel 等。
这些预处理工具能够将咱们的中间代码转换为可运行的 JavaScript。这些预处理器使得咱们能够事后应用 ECMA Script6，以结构化的形式编写 CSS，或者在 CommonJS 环境中编写 JavaScript 等等。
2、格调与测试
在一个典型的工作流中，每次 Push 主分支或 npm 公布都应首先运行代码格调检查和单元测试。咱们须要这些操作可能在适合的时候主动执行。
3、资源压缩
在开发网站代码时，咱们心愿模块化地进行编码。每个业务逻辑，通用工具，或者架构元素都须要组织在独自的文件中。然而如果用户浏览网页时也载入这么多源文件，那么页面关上速度会大打折扣。
因而在网站公布时须要将源码合并压缩，JavaScript 可能还会须要模块化（AMD，CommonJS 等），CSS 文件可能也须要合并、增加兼容性前缀（-webkit- , -moz-）等。这些重复性工作咱们也心愿写成脚本。
4、动态资源替换
最为简单的构建需要是动态资源的 URL 替换。因为生产环境中的资源地址可能和开发环境中很不一样，可能是因为 JS 合并、CSS 合并，也可能是因为利用了 CDN 减速。咱们须要在部署时更改所有 HTML 文件中的动态资源地址。
