前端构建工具的演变

这篇文章是我在试图搞清楚前端为什么发展出这样一套巨麻烦的工具链的过程当中作的笔记，在国内的社区里关于这方面的文章彷佛少有讲得通透的（我没找到），最后在外网上面找到了两篇很棒的文章，推荐你们阅读：

• Modern JavaScript Explained For Dinosaurs 以咱们熟悉的形式开始：html 文件引用一个 js 文件，一步步讲解为何须要使用[npm，模块打包，babel,...]等等工具，
• NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack 对比各个工具，比较他们的做用，不足。（是 Stack Overflow 上的一个提问，下面的高票回答都挺好的）

---

首先下个定义：

构建工具:用来让咱们再也不作机械重复的事情，解放咱们的双手的。

有哪些机械重复的事情？

在较早的前端开发中（js+css+html），有不少让咱们以为很不爽的地方，好比：

• js 的弱类型
• css 的编程性
• 手动维护依赖很麻烦
• 资源请求须要更快
• 没有热更新
• 浏览器的兼容性
  ......

这些需求催生出了一批前端工具，好比
ts/scss/JSMin/......

来进行如下这些工做：

1. 代码检查
2. 运行单元测试等
3. 语言编译
4. 依赖分析、打包、替换等
5. 代码压缩、spirit 图片压缩等
6. 版本生成
   ...

再进一步，一个个命令行去输入执行也是比较烦的
基于让机器代替咱们手动去执行这些工做的想法，整合这些工做的构建工具出现了

---

首先是包管理器

包管理器

是随着 node 出现的
在没有包管理器以前，维护所使用的第三方库每每须要到官网下载包以及依赖，手动进行管理。
而包管理器包简化项目依赖项的安装和更新，不用再手动下载维护第三方包以及其依赖。

这一类工具备 npm/bower/yarn

JavaScript module bundler

//index.js
var moment = require（'moment'）;
moment.func()

这样的代码在 node 是没有问题的，由于 node 能够访问计算机的文件系统。node 还知道每一个 npm 模块路径的位置，所以无需这样写require('./node_modules/moment/min/moment.min.js)，只需 require('moment')

而问题在于 require 浏览器是没法识别的，这就须要模块打包器

模块捆绑器从入口文件开始，查找任何 require 语句，而后将它们替换为适当的代码最后建立单个输出文件。最后在 html 中引用这个输出文件。并且把依赖打包到一个文件而且压缩能够在必定程度上解决 http 链接过多的问题

这类的工具备Browserify webpack

task runner

咱们想自动执行全部可自动化执行的任务而不是手动执行多个命令行代码，好比编译 scss，压缩代码，lint...

有些像 linux 中使用&& 去执行一系列任务。

这类的工具备 grunt/gulp/npm

grunt/gulp的最大不一样在于：grunt 每次任务都须要读写文件。而 Gulp 基于 node stream，同时配合了一系列插件去处理流，流能够在插件之间传递。

而 npm 内置了脚本功能，经过调用其余命令行工具来执行任务。npm 再配合 webpack webpack-dev-server eslint-loader等等使得前端开发高效便捷且规范。

脚手架

用来建立初始项目,而且作好上面所提到的一系列配置。

如各个框架提供的 Cli 工具、Yeoman

总结

gulp、grunt、browserify、webpack、rollup 等等构建工具都经过插件的形式集成了 sass 编译成 css、图片压缩...等等功能。其中 webpack 更侧重模块（图片、js 文件、css 文件等）打包，对资源进行处理，打包成符合生产环境部署的前端资源。gulp、grunt 则旨在规范前端开发流程。若是应用场景中是打包 js 库，但愿作 ES 转换，模块解析，可使用 Rollup 相比 webpack 会更简练。

参考文章

• Modern JavaScript Explained For Dinosaurs

• 前端构建工具对比

• NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack