当前位置: 主页 > 前端开发

前端自动化构建工具-前端自动化构建工具

发布时间:2023-02-08 11:07   浏览次数:次   作者:佚名

前言

随着前端项目的规模和复杂度不断增加,各种构建思路和相应的工具层出不穷。 本文尽量对比目前的13款构建工具,包括Browserify、Webpack、Rollup、Grunt、Gulp、Yeoman等六大热门工具,FIS、Athena、WeFlow、Cooking等四大国产工具,三大框架:官方脚手架适用于 React、Vue 和 Angular。 希望能为大家在工程前期施工工具的选择上提供一些参考。

概述

构建工具可以分为模块化打包、任务流构建和采集工具(脚手架)三大类。 最突出的是用于模块化打包的 Webpack 和用于任务流构建的 Gulp。 以下是截至2018年11月28日某个时刻GitHub上各个工具的Star数(听说Star数可以造假?无聊的家伙们!)。

前端自动化构建工具_前端自动化构建工具_构建学习化社会

前端建设一般包括JS转码(使用Babel转ES6或TypeScript自动转等)、CSS转码(Less或Sass转Css)、代码或资源合并压缩、基础检查和各种测试等。虽然这些与本文密切相关,不在讨论范围之内。 原因有二:一是这些功能是通过一些插件实现的,而不是工具本身,各种构建工具直接或间接使用它们(调用自己封装的插件模式); 另一个是本文介绍的,构建方向的分类和每个分类中不同工具的区别与具体操作无关。

模块化封装类

现在的前端项目基本都是模块化的,这里就不多说原因了。 模块化意味着分散,不能直接用于展示,需要相应的打包形成一个整体。 一些执行环境(Node)可以自动打包单个模块前端自动化构建工具,而另一些(浏览器)出于技术或其他考虑需要自己完成。 模块化打包工具用于在浏览器上优化呈现模块化项目。

模块化打包的核心是找出依赖关系并将它们打包成一个整体。 各种工具的基本运行思路是,从某个文件开始,根据已有的配置,递归查找与其相关的所有依赖模块,并将其打包成一个或多个可以直接在浏览器中运行的新模块。 文档。 除此之外,还可以针对代码分离、异步加载和长期缓存等高级功能优化输出。

浏览器化

官方网站 | GitHub

Browserify 官网介绍,Browserify 会递归解析并打包项目中 require 引入的所有 JS 模块(包括 Node 内置模块),从而使 Node 项目可以在浏览器上运行。 但项目相关的其他资源,如css、图片等,还是需要手动管理。 虽然网上有人写了插件来支持这些功能,但这不仅违背了设计初衷,而且配置也很乱。 而对于要求越来越高的单页应用,它所能提供的帮助实在是让人疲惫不堪。

网页包

官方网站 | 中文 | GitHub

稳定版已到v4.26.0,本文基于此版本。 另附上官方对比文件。

构建学习化社会_前端自动化构建工具_前端自动化构建工具

Webpack的设计思想新颖实用,社区活跃,功能强大全面。 已经是最好的各种前端资源的模块化管理和打包工具。 上手简单,基本的常用功能可以快速上手,用于实际开发。 但掌握它并不容易。 毕竟,打包是 Web 开发中最重要的挑战之一,必须付出一些努力。 学起来不容易,介绍起来就更难了,必须厚如书。 好在这一段不是详细的介绍,而是亮点的阐述,很好很好。

入门变得更容易

一旦掌握了构建的基本思路,上手任何工具都比较简单(读者评论:废话)。 Webpack之所以容易上手,是为了减轻有兴趣的人在学习之前的顾虑。 一方面,刚推出时,由于概念新颖,文档不全,开发者处于懵懂状态,总觉得离真相还很远。 另一方面,它的系统实在是太庞大了,仔细想想都胆小。 这些是我第一次接触它时的感受。

但现在不同了。 吃土的日子已经过去了,但吃草的梦想还会远吗? 大家准备好你的镰刀!

Webpack第四版的入门便利性体现在三个方面。 首先,基础功能高度集成,约定好于配置思路:安装Webpack及其CLI后,可以直接打包JS和JSON文件,和Browserify一样简单。 二是官方文档很详细(而且有基本同步的中文版),无论是概念解析、实例还是界面展示都非常完备。 三是现在已经有很多人在使用和介绍Webpack,所以网上的资料和相应问题的解决方案也非常多。 你还在犹豫?

一切都是模块

如官网截图所示,所有文件(.js、.css、.jpg、.woff、.csv、.ts等,除了一些下载的静态大文件)在Webapck眼中都是模块. 两者都可以用类似JS的方式打包,放在合适的浏览器渲染位置。 真正的立足点。 有了这个思路,几乎所有前端会用到的资源都可以包含进来,统一管理和放置,更加方便高效。

而这个想法就是为单页应用而生的。 在Webpack的另一种意境中,asset(各种资源)是module,component是module,module也是module。 单页应用的特点是应用的更新不是整个页面的更新,而是某个模块或者组件或者资产的更新? 很适合。

有人说 Webpack 的缺点是服务端渲染(或者说多页面应用)。 哎,一来别人的目标不在这里,二来多页应用不需要那么复杂的支撑体系。

高效的构建性能

单页应用或者需要构建展示的应用,相对于多页应用,从每次修改到重新渲染都要多经历一个构建阶段。 在实际操作中,如果项目庞大,构建性能优化不够,一个小小的修改(打印某个值)就会消耗5秒以上,这对开发者来说真是地狱! 优化的方法无外乎两点,一是开发者优化项目的构建思路前端自动化构建工具,二是构建工具优化自身的构建性能。

Webpack 具有理想的构建性能。 在开发阶段,当开启Webpack的模块热替换时(使用webpack-dev-server时会自动开启),一旦检测到文件被修改,会最小化替换,添加或移除模块,无需重新加载整个页面。 类似于Dom渲染中的回流:如果子元素的大小发生变化,影响的是兄弟元素,不会影响父元素,那么父元素等不需要重绘。 即使完全重建,之前的应用程序状态也会保留下来,从而减少等待时间。

活跃的社区

一个活跃的社区可以增加系统的丰富性,降低学习和使用它的成本。

Webapck社区非常活跃,各种需求的插件都被一一封装,可以直接使用(官方也展示和解释了一些常用的优秀Loader和Plugins)。 不仅是其他工具的高度协同,还有开发的各个阶段:构建本地服务器、集成测试等,以及与任务流工具(Gulp、Grunt)等集成的解决方案或最优方案。 ,内容丰富全面。 基本上,可以想象的需求,在这个社区里,可以直接借鉴别人的成果。

卷起

官方网站 | 中文 | GitHub

Rollup定位为JS模块打包器(JS),主要用于构建JS库,也可以服务于一些不需要代码拆分和动态导入的小应用。 能够在Webpack已经稳居打包第一,并得到Vue、D3、Three、React等知名库青睐的情况下,打出一条血路,想必有它的起点和表现。

Rollup本身结构简单,配置项少,文档完善,易于上手和掌握。 它使用 ES6 自己的 Module 语法作为自己的标准,而不是以前的 CommonJS 和 AMD 等解决方案。 这意味着按照Module标准编译的代码,不仅现在可以用Rollup打包运行,未来也可以直接在实现该标准的浏览器上运行。

Rollup通过Module的特性创建了项目中没有用到的Tree-shaking功能清空代码。 它基于显式的导入导出语句,通过静态分析排除任何未使用的代码,可以大大减少构建在现有模块上的项目大小。 另外,它的构造基本不加自己的控制代码,使打包后的文件真正纯净。 想想还是有点痒,我挠了挠裤裆。

与 Webpack 相比

Rollup 和 Webpack 之所以能够共存、相互支持,是因为定位和侧重点。

正如Rollup官网所说,Rollup更适合构建独立的JS库,而Webpack则是资源丰富的应用。 虽然 Webpack 也加入了自己的 Tree-shaking 功能,但是简单地运行自动 minifier 来检测编译输出代码中未使用的变量,不如原生的静态分析。 更何况Webpack生成的代码一定是自己打包后的代码——每个模块都封装在一个函数中,然后放在一个包中,通过浏览器可以使用的require方法将这些模块一个一个执行。

任务流构建类

基于任务的构造行为不关心操作对象是否模块化。

此类工具的目标是通过配置(转换、合并压缩、单元测试等)释放例行的重复性工作。 有人说:Webpack 和 Rollup 不也可以做这些操作吗? 是的,基本上可以做到。 事实上,任务流构建工具很少用于模块化构建工具的开发中。 但这绝不意味着任务流工具会或不会被取代,至少对于多页面应用程序而言。 再说了,任务流工具是一个很纯粹的自动化行为,跟模块化打包工具的立足点是不一样的,何必谈取而代之。

咕噜声

官方网站 | 中文 | GitHub

Grunt虽然是一个老牌的构建工具,但仍然被WordPress、Twitter、Jquery等众多知名项目所使用,而且它也拥有完整的生态系统和不断更新的中文文档。 由配置驱动——通过获取的JSON配置执行操作,以流水线的方式执行相应的任务。 虽然在学习成本和执行效率上并不突出,但如果项目本来就是通过它自动构建的,就没有必要迁移到其他工具上了。

  1. // Grunt 的配置驱动示例

  2. module.exports = function(grunt) {

  3.  grunt.initConfig({

  4.    jshint: {

  5.      files: ['Gruntfile.js', 'src/**/*.js', 'test/**/*.js'],

  6.      options: {

  7.        globals: {

  8.          jQuery: true

  9.        }

  10.      }

  11.    },

  12.    watch: {

  13.      files: ['<%= jshint.files %>'],

  14.      tasks: ['jshint']

  15.    }

  16.  });


  17.  grunt.loadNpmTasks('grunt-contrib-jshint');

  18.  grunt.loadNpmTasks('grunt-contrib-watch');


  19.  grunt.registerTask('default', ['jshint']);


  20. };

咕噜咕噜

官方网站 | 中文 | GitHub

Gulp 是一个新的构建工具。 虽然它具有与 Grunt 相同的功能,但其构建过程具有三个优点。

代码驱动

Code driver是通过执行实际的code driver来执行的,区别于常见的configuration driver(Webpack、Rollup、Grunt等都是configuration driver)。 从任务流构建的角度来看,代码驱动相对于配置驱动具有三个优势:一是高度灵活; .

  1. // Gulp 的代码驱动示例

  2. gulp.src('./client/templates/*.jade')

  3.  .pipe(jade())

  4.  .pipe(gulp.dest('./build/templates'))

  5.  .pipe(minify())

  6.  .pipe(gulp.dest('./build/minified_templates'));

节点流程

Gulp作为后来者,充分利用了NodeJS流的思想进行IO操作,大大提高了大型项目的构建速度。 比如将Scss转为Css,Grunt的操作流程为:读取Scss文件,转为Css,存入磁盘,读取Css,压缩,存入磁盘; 而Gulp的操作是:读取Scss文件,转换为Css并进行压缩处理,最后存入磁盘。 一步到位,无需多次IO操作。

容易明白

Gulp 有一个非常紧凑的 API。 你能想到基本上只用五个可以链接的方法就可以实现的各种类型的任务吗? 不仅易学易用,编写后的功能也一目了然。 code driver虽然比configuration driver需要写更多的代码,但是一来难度没有增加但是函数名改写了多次,二来和code driver的好处相比可以忽略不计。

采集工具

采集工具类常被称为脚手架,也可以看作是对各种常用工具的高度封装,以模块化或任务流工具为主体。 它是一个开箱即用的集合,类似于前后端同构时代的后端框架。 根据您的选择,它会生成一个完整的项目框架,其中配置了各种工具和一定的代码约定。 这些配置几乎涵盖了前端开发的全过程,甚至可以集成自动化部署等后端接口。

官方框架

反应 CLI | 命令行界面 | 角 CLI

采集工具一般服务于单页应用,而单页应用需要使用一定的前端框架。 不管你用的是 React、Vue 还是 Angular,或者其他框架,你首先得想清楚它有没有官方的脚手架。 比如 Vue 有 VueCLI。 一般建议直接使用官方脚手架。 因为现代前端框架一般不会单独运行,需要结合其他官方工具,比如路由、状态管理等。 而且各种框架和配件不断更新,每次更新都可能会导致与其他插件的兼容性问题,新的功能可能需要某些特定的插件才能发挥作用。 这是一个单靠个人或团体无法完全完成的项目。 并且每个框架都有意识地使用官方脚手架,充分展示新特性,降低学习和使用成本。 为什么不这样做呢?

约曼

官方网站 | GitHub

Yeoman 是一种灵活且多功能的现代前端脚手架工具。

它的工作方式不同于其他脚手架。 安装CLI后,需要找到符合要求的Generator(一个npm包,相当于脚手架),使用Yeoman运行安装,生成初始化工程。 也可以自己配置,使用Yeoman打包成满足特定需求的Generator,发布。 下次别人或者自己需要生成满足这个需求的项目时,可以直接安装使用Yeoman生成。

这样做有两个明显的好处:一是节省能源。 在开始有特定需求的新项目时,如果有旧项目可供参考,一般直接复制相关文件。 但是,这样复制的文件可能并不纯粹,即增加了体积,带来了安全隐患。 第二,在社区的支持下,很多有特殊需求的脚手架都已经解决并作为生成器发布了,不用自己动手了。

国内其他

百度-FIS-官方网站| GitHub

微信-WeFlow-官网| GitHub

京东-雅典娜-官网| GitHub

Are you hungry-Cooking(名字符合公司性质)-官网| GitHub

作为程序员或者身处各行各业,在对应年龄增长速度的压力下,薪水高低自然成为了日常的评价标准。 但在同业老友的酒桌上,或者在异常温暖的阳光下的路上,最能让自己为自己骄傲而不是其他的,一定是“我以前做过什么”的实际付出,而不是物质上的收获. 所以,能够在公司支持的开源框架维护团队里成为一名程序员,被很多人使用,多少有些幸福。

国内各个前端团队开发的这些集体脚手架,都是基于在实践中得到的最符合自己需求的产品,供自己使用。 它包含的内容非常多,不仅有上面提到的前端工作,还有与后端的集成方案或者自动部署配置。 并且简化了流程,开箱即用。 但是,我从来没有使用过这些,也不打算使用它们。 不是开玩笑,理由很现实,有识之士可以在文下留言。 之所以还写着没用,原因很简单:宣传,宣传就是赞美和期待; 凑数,凑13种来做一些夸张的标题。

总结

个人观点,不喜请喷,请见谅。

如果你是使用某个前端框架开发应用,推荐使用该框架的官方脚手架。 如果你想凭着自己的热情开源一个JS库,推荐Rollup打包。 如果不是模块化项目,需要自动化一些东西,推荐使用Gulp作为构建工具。 如果项目有特殊需求或者核心组件比较少见,可以先看看Yeoman上是否有符合要求的Generator,没有的话就只能自己养了。 最后,如果你所在的公司已经有了自己的脚手架(比如饿了么),你可能要根据规章制度,用Cooking来为你的职业生涯做一些美食。 好饿啊,这样的宣传能打赏券吗?

最后,如果你是自己搭建之前没人见过的脚手架,推荐使用Yeoman来发布,方便你我。