前端打包、编译和优化(前端项目打包命令)
 南窗  分类:IT技术  人气:104  回帖:0  发布于1年前 收藏

打包

目前前端世界主流的前 3 名模块打包器仍然是 Webpack Rollup Esbuild

Webpack

本质上,Webpack 是一个用于现代 JavaScript 应用程序的静态模块打包工具。当 Webpack 处理应用程序时,它会在内部从一个或多个入口点构建一个 依赖图(dependency graph) ,然后将你项目中所需的每一个模块组合成一个或多个 bundles,它们均为静态资源,用于展示你的内容。

使用如下命令来安装:webpacknpm install webpack -g

安装完后,可以输入webpack -v 命令查看是否安装成功。

文档:https://webpack.docschina.org/concepts/

Esbuild

Esbuild 是一个用 Go 编写的模块打包工具。因为它大量利用了 Go 中并行的特性,所以 Esbuild 非常快。

  • Esbuild 内部的算法经过精心设计,在可能的情况下它将饱和使用所有可用的 CPU 内核
  • Esbuild 中的所有功能在开始编写时就充分考虑了性能

文档:https://esbuild.github.io/

Rollup

Rollup 是一个 JavaScript 模块打包工具,可以将多个小的代码片段编译为完整的库和应用。与传统的 CommonJS 和 AMD 这一类非标准化的解决方案不同,Rollup 使用的是 ES6 版本 Javascript 中的模块标准。

  • 与 Webpack 相比快速且轻量级
  • 支持 Tree Shaking

文档:https://www.rollupjs.com/

Parcel

Parcel 是一个众所周知的零配置 Web 应用程序打包器。

  • 默认启用 Tree Shaking
  • 使用 Rust 编写的 Javascript 编译器,以利用并行性并提高性能
  • 支持原生 ES Moduls 和 CommonJS 两种模块标准
  • 自动代码拆分

文档:https://parceljs.org/docs/

Turbopack

Turbopack 建立在 Turbo 之上:Turbo 是一种用于 Rust 的开源增量记忆框架。 Turbo 可以缓存程序中任何函数的结果。当程序被执行多次时,函数不会重新运行,除非它们的输入发生变化。

这种方法使 Turbopack 在计算增量更新方面非常快。这也优化了 Turbopack 使得开发过程中增量更新非常快,确保 dev server 能够快速响应代码变更。

Turbopack 还使用请求级编译方法来只编译请求的代码。如果浏览器请求某些 CSS,则只会编译该 CSS,而不编译引用的 images。采用请求级编译有助于减少请求数量并能够快速编译它们。

目前,Turbopack 比现有打包工具快 10 倍~700 倍。但它目前只可以在 Next.js v13 中使用。未来计划发布独立的 CLI、插件 API,并支持 Svelte 和 Vue 等其他框架。

文档:https://turbo.build/pack/docs

Nobundle:Vitejs

Vite 通过在一开始将应用中的模块区分为依赖源码两类,改进了开发服务的启动时间。

  • 依赖大多为在开发时不会变动的纯 JavaScript。一些较大的依赖(例如有上百个模块的组件库)处理的代价也很高。依赖也通常会存在多种模块化格式(例如 ESM 或者 CommonJS)。Vite 将会使用 esbuild (https://esbuild.github.io/) 预构建依赖(https://cn.vitejs.dev/guide/dep-pre-bundling.html)。
  • 源码通常包含一些并非直接是 JavaScript 的文件,需要转换(例如 JSX,CSS 或者 Vue/Svelte 组件),时常会被编辑。同时并不是所有的源码都需要同时被加载(例如基于路由拆分的代码模块)。Vite 以 原生 ESM (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules) 方式提供源码。这实际上是让浏览器接管了打包程序的部分工作:Vite 只需要在浏览器请求源码时进行转换并按需提供源码。根据情景动态导入代码,即只在当前屏幕上实际使用时才会被处理。

对于生产环境,Vitejs 使用 Rollup 进行打包。

文档:https://vitejs.cn/

编译工具

编译工具(Compiler)可以理解为将一种语言编写的源代码转换为另一种语言的过程。在前端开发过程中,我们经常遇到如下两类编译场景:

  1. 将 TS 转换为 JS;
  2. 将新版本 JS 语法转换为低版本浏览器支持的语法;

当前前端界的编译工具,如下四个占据了大部分市场:

名称

描述

Star

底层语言

Babel (https://babeljs.io/)

JS 编译器,用于将新版本 JS 语法转换为向后兼容的 JS 语法。也可以通过插件(https://babeljs.io/docs/en/babel-plugin-transform-typescript)支持 TS 语法编译,但不支持类型检查。

41.8K

JS

TSC (https://www.typescriptlang.org/)

TS 官方编译器,用于将 TS 编译成 JS。同时也支持旧版本语法转换,但不能自动 polyfill。

87.5K

TS

SWC (https://swc.rs/)

新一代 JS 编译器,特点是速度非常快,宣称单核下比 Bable 快 20 倍。支持 TS 编译,但不会做类型检查。

25.5K

Rust

esbuild (https://esbuild.github.io/)

一款超级快且融合编译&打包的工具,宣称比现在生态(说的就是你:webpack + babel)快10-100倍。支持 JS/TS,编译 TS 不会做类型检查。

34.3K

Go

Babel

最早开始出现 JS 编译工具之一,也是目前使用最多的 JS 编译工具。随着 Babel 的出现,前端开发者可以直接编写现代 JS 代码,同时又不失去对旧浏览器的支持。

简单来说,Babel 是一个工具链,主要用于将 ECMAScript 2015+ 版本的代码转换为向后兼容的 JavaScript 语法,以便能够运行在当前和旧版本的浏览器或其他环境中。Babel 可以做如下事情:

  • 语法转换,比如 constlet?. 、箭头函数等
  • 最新 ES API 和 ES 实例/静态方法的 Polyfill,如 PromiseArray.prototype.includes 等。这部分主要通过第三方库来 polyfill,如 core-js (https://github.com/zloirock/core-js)
  • 源码转换(codemods)

Babel 官方提供一个 在线编译网站(https://babeljs.io/repl),大家可以使用它便捷的体验 Babel 的编译效果。

Babel 构建在插件之上,默认情况下,Babel 不做任何处理,需要借助插件来完成语法的解析、转换、输出。

TSC

TSC(TypeScript Compiler) 是 TS 语言官方的编译器,最初 TS 语言只能使用 TSC 进行编译,随着 Babel 等工具也相继支持编译 TS,你可能有疑问,他们之间有什么区别吗?答案是有的, 相对于 Babel,TSC 有如下 优势

  • 可以进行类型检查;
  • 可以识别所有的类型并生成 .d.ts 类型文件;

原因在于 Babel 是单个文件编译的,不会解析其他文件的信息,而 TSC 的类型检查需要拿到整个工程的类型信息,需要做类型的引入、多文件 namespace 的合并等。而 Babel 编译 TS 只是去掉类型声明,保留原有 JS 功能。

通过配置 target 也可以让 TSC 编译出低版本浏览器支持的代码,但存在一些 缺点:

  • 对一些新语法缺乏支持,如提案阶段的语法;
  • 对于 ES API 和 ES 实例/静态方法无法解析,需要单独添加 polyfill

综上,现在的前端 TS 项目一般还是会使用 Babel 做编译,使用 TSC 做类型检查。

Babel for transpiling, TSC for types :

(https://www.typescriptlang.org/docs/handbook/babel-with-typescript.html#handbook-content)

SWC

一款基于 Rust 语言开发的编译工具,它相对于 Babel 的优势就是编译速度非常快,在它的官网上,写着如下一句话。

SWC is 20x faster than Babel on a single thread and 70x faster on four cores.

SWC 的成功得益于 Rust 语言,这是一门高效、性能更好且内存安全的语言。随着 SWC 的崛起,很快它就被 Next.js 采用,进而取代 Babel 作为 JS 编译工具。

优缺点:

SWC 最大的优势就是编译速度快,另外在可扩展性、WASM 支持、社区和生态系统方面也是做的非常不错的。

但是,如果从 Babel 切换到 SWC,也有一些问题需要考量:

  • 相对于 Babel SWC 的编译支持上有一些区别,参考 官方列表 (https://swc.rs/docs/migrating-from-babel) 可能会导致代码的浏览器支持度降低
  • SWC 也有插件系统,但仍是实验性的,且开发插件要学习 Rust 和 WebAssembly,上手门槛明显很高

SWC 并不满足只是一个编译工具,未来或将支持如下能力

  • 编译工具,替代 Babel
  • 打包器,替代 Webpack,目前正在建设中:swcpack (https://swc.rs/docs/usage/bundling)
  • 类型检查器,替代 TSC
  • 压缩器,替代 Terser

esbuild

esbuild 更多是作为打包工具被大众熟知,我们在打包工具章节也做了介绍。

其实 esbuild 也是支持编译能力的,且速度要比 Babel 快很多,但是它不兼容低版本浏览器,产物无法降级到 ES6 以下。esbuild 也原生支持编译 TS 语言,同样不支持类型检查,遗憾的是官方也没有计划去做这件事。

优化技术

1、LightHouse

通过LightHouse获取页面FCP (First Contentful Paint)和Speed Index指标,首屏加载FCP要尽量减少白页,Speed Index越快越好(最多4s内) 2、Frame Rate

通过Frame Rate 工具检测页面FPS,遇到轮播图动画等页面交互时应该尽量保证fps流畅,防止用户观看时出现卡顿闪烁等视觉体验 3、NetWork

通过瀑布图NetWork,直观的看到接口的响应速度,尽量缩短响应的速度,同时也能看到一个页面的接口请求数,减少同时并发的请求,把不重要的请求往后排序,来提升性能 4、Performance

通过Performance监听主线程性能,尽量减少DOM加载时间

参考:https://blog.csdn.net/m0_68324632/article/details/127487822

5、Tree Shaking

摇树优化Tree Shaking是Webpack里非常重要的优化措施,它的优化效果在Webpack 5中又得到了进一步的提升。Tree Shaking可以帮我们检测模块中没有使用到的代码块,并在Webpack打包时将没有用到的代码块移除掉,减小打包后的资源体积大小。它的名字也非常形象,通过摇晃树把树上干枯无用的叶子摇掉。

参考:https://zhuanlan.zhihu.com/p/467104092

讨论这个帖子(0)垃圾回帖将一律封号处理……