Exposition of Frontend Build Systems

August 4, 2024

原文：https://sunsetglow.net/posts/frontend-build-systems.html
其它翻译：https://juejin.cn/post/7398480670445895743

开发者编写 JavaScript；浏览器运行 JavaScript。从根本上说，前端开发无需构建步骤。那么，为何在现代前端开发中我们需要构建步骤呢？

随着前端代码库的不断扩大，同时开发者的使用体验变得越来越重要，若直接将 JavaScript 源代码发送到客户端会导致两个主要问题：

不支持的语言特性： 由于 JavaScript 运行在浏览器中，并且市面上存在各种版本的浏览器，每使用一个新的语言特性都会减少能够执行你的 JavaScript 的客户数量。
此外，像 JSX 这样的语言扩展并不是有效的 JavaScript，在任何浏览器中都无法运行。
性能问题： 浏览器必须单独请求每个 JavaScript 文件。在一个大型代码库中，这可能会导致数千次 HTTP 请求来渲染一个页面。
在过去，在 HTTP/2 出现之前，这也会导致数千次 TLS 握手。

译注：这里的表述有误。在 HTTP/1.1 中，浏览器可以通过持久连接重用同一个 TCP 连接进行多个请求，但仍然会有一定数量的握手。HTTP/2 进一步优化了这种情况，通过单个连接并行传送多个请求，显著减少了握手的开销。

此外，在所有 JavaScript 都加载完之前，可能需要几次连续的网络往返。例如，如果 index.js 导入 page.js，而 page.js 导入 button.js，那么需要三次连续的网络往返才能完全加载 JavaScript。这被称为瀑布问题。

源文件的体积也可能由于长变量名和空白缩进字符而变得不必要的大，增加了带宽使用和网络加载时间。

前端构建系统处理源代码，并生成一个或多个优化后可发送到浏览器的 JavaScript 文件。最终的构建产物通常对人类来说是难以阅读的。

构建步骤

前端构建系统通常包括三个步骤：转译（transpilation）、打包（bundling）和压缩（minification）。

有些应用程序可能无需所有的三个步骤。例如，较小的代码库可能不需要打包或压缩，而开发服务器可能为了性能而跳过打包和/或压缩。也可以添加一些自定义步骤。

译注：
例如，vite 的开发服务器基于原生 ESM 模块，它通过 esbuild 做依赖预打包以减少浏览器请求数量，并进行 CommonJS 到 ESM 的转换。
webpack 需要自行配置开发模式，若选择 webpack-dev-server，它通过将构建产物置于内存而非硬盘来优化访问速度。

有些工具实现了多个构建步骤。特别是，打包工具通常会实现所有三个步骤，单一的打包工具可能足以构建简单的应用程序。复杂的应用程序可能需要专门的工具来完成每个构建步骤，这些工具提供更强大的功能集。

转译（Transpilation）

转译通过将使用现代 JavaScript 版本编写的代码转换为较旧的 JavaScript 版本，解决了不支持的语言特性问题。目前，ES6/ES2015 是一个常见的目标。

框架和工具也可能引入转译步骤。例如，JSX 语法必须转译成 JavaScript。如果某个库提供了 Babel 插件，这通常意味着它需要一个转译步骤。此外，像 TypeScript、CoffeeScript 和 Elm 这样的语言必须转译成 JavaScript。

CommonJS 模块 (CJS) 也必须转译成浏览器兼容的模块系统。在 2018 年浏览器普遍支持 ES6 Modules (ESM) 之后，转译为 ESM 一般是推荐的。由于 ESM 的导入和导出是静态定义的，因此更容易优化和树摇。

目前常用的转译器有 Babel、SWC 和 TypeScript 编译器。

Babel（2014）是一个标准的转译器：使用 JavaScript 编写的单线程转译器。许多需要转译的框架和库通过 Babel 插件完成转译，这就需要 Babel 成为构建过程中不可或缺的一部分。然而，Babel 难以调试，并且常常令人困惑。
SWC（2020）是一个使用 Rust 编写的快速多线程转译器。它声称比 Babel 快 20 倍，因此被较新的框架和构建工具所使用。它支持转译 TypeScript 和 JSX。如果你的应用程序不依赖 Babel，SWC 是一个更好的选择。
TypeScript 编译器 (tsc) 也支持转译 TypeScript 和 JSX。它是 TypeScript 的参考实现，也是唯一全功能的 TypeScript 类型检查器。然而，它非常慢。尽管 TypeScript 应用程序必须通过 TypeScript 编译器类型检查，但对于构建步骤，使用替代的转译器会更高效。

如果你的代码是纯 JavaScript 且使用 ES6 模块，则可能可以跳过转译步骤。

另一种解决不支持语言特性的方法是使用 polyfill。polyfill 在运行时执行，在执行主应用程序逻辑之前实现缺失的语言特性。然而，这增加了运行时开销，而且某些语言特性无法通过 polyfill 实现。参见 core-js。

所有打包工具本质上也是转译器，因为它们解析多个 JavaScript 源文件并生成一个新的打包的 JavaScript 文件。在此过程中，它们可以选择在其生成的 JavaScript 文件中使用哪些语言特性。有些打包工具还能够解析 TypeScript 和 JSX 源文件。如果你的应用程序有简单的转译需求，你可能不需要单独的转译器。

打包（Bundling）

打包解决了需要许多网络请求和瀑布问题。打包工具将多个 JavaScript 源文件拼接为一个单一的 JavaScript 输出文件，称为 bundle，而不改变应用程序行为。这样，浏览器可以通过一次往返网络请求高效加载 bundle。

当前常用的打包工具有 Webpack、Parcel、Rollup、esbuild 和 Turbopack。

译注：vite 基于 rollup，swc 也实现了打包功能。另外还有 rolldown、rspack、farm 等等

Webpack（2014）在 2016 年左右变得非常流行，后来成为标准的打包工具。与当时常用的 Browserify 不同，Webpack 开创了可以在导入时转换源码文件的“loaders”，使得 Webpack 能够协同整个构建流水线。

Loaders 允许开发者在 JavaScript 文件中透明地导入静态资源，将所有的源码文件和静态资源组合成一个单一的依赖图。而在使用 Gulp 时，每种类型的静态资源都必须作为一个单独的任务构建。Webpack 还开箱即用的支持代码拆分，简化了其设置和配置。

Webpack 速度慢且是单线程的，用 JavaScript 编写。它高度可配置，但许多配置选项可能让人困惑。
Rollup（2016）利用 ES6 模块的广泛浏览器支持及其优化能力（如树摇），生成的 bundle 比 Webpack 小得多，导致 Webpack 也后来采用了类似的优化。Rollup 是一个单线程的打包工具，用 JavaScript 编写，性能仅略优于 Webpack。
Parcel（2018）是一个少配置的打包工具，旨在“开箱即用”，为构建过程的所有步骤和开发者工具需求提供合理的默认配置。它是多线程的，比 Webpack 和 Rollup 快得多。Parcel 2 在内部使用 SWC。
Esbuild（2020）是一个为并行处理和优化性能而设计的打包工具，用 Go 编写。它的性能比 Webpack、Rollup 和 Parcel 快数倍。Esbuild 实现了一个基本的转译器和一个压缩器，但功能不如其它打包工具，它提供了一个有限的插件 API，不能直接修改 AST。与其使用 esbuild 插件修改源文件，不如在传给 esbuild 之前先对文件进行转换。
Turbopack（2022）是一个支持增量重建的快速 Rust 打包工具。该项目由 Vercel 开发，Webpack 的创建者领导。目前处于 Beta 版，可在 Next.js 中可选使用。

如果你有非常少的模块或网络延迟非常低（如在 localhost 上），跳过打包步骤是合理的。有些开发服务器也选择不在开发时打包模块。

代码拆分（Code Splitting）

默认情况下，客户端 React 应用程序被转化为一个单一的 bundle 文件。对于具有许多页面和功能的大型应用程序，bundle 文件可能非常大，抵消了打包的原始性能优势。

将 bundle 文件划分为几个较小的 bundle 文件，即代码拆分，可以解决这个问题。一种常见的方法是将每个页面拆分为一个单独的 bundle 文件。使用 HTTP/2，可以将共享的依赖项也分离成独立的 bundle 文件，从而避免重复且几乎没有成本。此外，大型模块可以拆分为单独的 bundle 文件并按需懒加载。

代码拆分后，每个 bundle 文件的大小大大减少，但会需要额外的网络往返，这可能重新引入瀑布问题。因此代码拆分是一种权衡。

被 Next.js 普及的文件系统路由优化了代码拆分的权衡。Next.js 为每个页面创建单独的 bundle 文件，只在 bundle 文件中包含该页面导入的代码。加载一个页面时并行预加载该页面使用的所有 bundle 文件。这优化了 bundle 文件大小，而不会重新引入瀑布问题。文件系统路由通过为每个页面创建一个入口点（pages/**/*.jsx）来实现这一点，而不是传统客户端 React 应用程序的单一入口点（index.jsx）。

树摇（Tree Shaking）

一个 bundle 文件由多个模块组成，每个模块包含一个或多个导出项。通常，一个给定的 bundle 文件只会使用其导入模块的一部分导出项。打包工具可以在一个称为树摇的过程中移除其模块中未使用的导出项。这优化了 bundle 文件大小，提高了加载和解析时间。

树摇依赖于对源文件的静态分析，因此当静态分析变得更具挑战性时会受到阻碍。两个主要因素影响树摇的效率：

模块系统： ES6 模块是静态导出和导入，而 CommonJS 模块是动态导出和导入。因此，打包工具在对 ES6 模块进行树摇时能够更加激进和高效。
副作用： package.json 的 sideEffects 属性声明模块在导入时是否有副作用。当存在副作用时，由于静态分析的限制，未使用的模块和导出项可能无法被树摇掉。

静态资源（Static Assets）

静态资源，如 CSS、图片和字体，通常在打包步骤中添加到产物中。它们也可以在压缩步骤中进行文件大小优化。

在 Webpack 出现之前，静态资源作为独立的构建任务从源码中单独构建。为了加载静态资源，应用程序必须通过其产物中的最终路径引用它们。因此，常常会根据 URL 约定来仔细组织资源（如 /assets/css/banner.jpg 和 /assets/fonts/Inter.woff2）。

Webpack 的“loaders”允许从 JavaScript 中导入静态资源，将代码和静态资源统一到一个依赖图中。在打包过程中，Webpack 会用其在产物中的最终路径替换静态资源导入。这一特性使静态资源可以与其相关组件一起在源码中组织，并创造了新的静态分析可能性，如检测不存在的资源。

需要注意的是，导入静态资源（非 JavaScript 或转译成 JavaScript 的文件）不是 JavaScript 语言的一部分。这需要配置支持该资源类型的打包工具。幸运的是，跟随 Webpack 的打包工具也采用了“loaders”模式，使这一特性普遍化。

压缩（Minification）

压缩解决了文件不必要大的问题。压缩工具在不影响文件行为的前提下减小文件大小。对于 JavaScript 代码和 CSS 资源，压缩工具可以缩短变量、消除空白和注释、消除无用代码，并优化语言特性的使用。对于其它静态资源，压缩工具可以进行文件大小优化。压缩工具通常在构建流程结束时对 bundle 文件运行。

目前常用的 JavaScript 压缩工具有 Terser、esbuild 和 SWC。
Terser 是 fork 自不维护的 uglify-es ，用 JavaScript 编写，速度比较慢。Esbuild 和 SWC 在前文提到，这两者除了其它功能外，还实现了压缩器，比 Terser 更快。

常用的 CSS 压缩工具有 cssnano、csso 和 Lightning CSS。
Cssnano 和 csso 是用 JavaScript 编写的纯 CSS 压缩工具，速度较慢。Lightning CSS 是用 Rust 编写的，声称比 cssnano 快 100 倍。Lightning CSS 还支持 CSS 转换和打包。

开发者工具（Developer Tooling）

上述基本的前端构建流水线足以创建一个优化的生产构建产物。还有几类工具可以增强基本的构建流水线并改善开发者体验。

元框架（Meta-Frameworks）

前端领域以选择“正确”包的挑战而著称。例如，上述五个打包工具中，你该选择哪一个？

元框架提供了一套已经选好的包组合，包括构建工具，这些包协同工作以实现特定的应用模式。例如，Next.js 专注于服务器端渲染 (SSR)，Remix 专注于渐进增强。

元框架通常提供预配置的构建系统，免去了你需要自己去拼装一个的麻烦。它们的构建系统为生产环境和开发服务器提供配置。

与元框架类似，构建工具如 Vite 提供用于生产和开发的预配置构建系统。然而，它们不强制采用特定的应用模式，适用于通用的前端应用程序。

源映射（Sourcemaps）

构建流水线输出的产物可以说是人类不可读的。这使得发生错误时调试很困难，因为其错误堆栈指向难以理解的代码。

源映射解决了这个问题，通过将产物中的代码映射回其源码中的原始位置。浏览器和诊断工具（如 Sentry）使用源映射恢复并显示原始源码。在生产环境中，源映射通常隐藏在浏览器中，仅上传到诊断工具以避免公开源码。

构建流水线的每一步都可以生成一个源映射。如果使用多个构建工具来构建流水线，源映射将形成一个链（如 source.js -> transpiler.map -> bundler.map -> minifier.map）。要识别压缩代码对应的源代码，必须遍历源映射链。

然而，大多数工具无法解释源映射链；它们期望每个产物中的文件最多只有一个源映射。必须将源映射链展平成一个单一的源映射。预配置的构建系统会解决这个问题（参见 Vite 的 combineSourcemaps 函数）。

热重载（Hot Reload）

开发服务器通常提供热重载功能，当源代码改变时自动重建一个新的 bundle 文件并重新加载浏览器。尽管比手动重建和重载要好许多，但它仍然有些慢，并且重新加载时所有客户端状态都会丢失。

热模块替换（Hot Module Replacement，HMR）改进了热重载（Hot Reload），通过在运行中的应用程序中就地替换更改的 bundle 文件。这样保留了未改变模块的客户端状态，并减少了代码变更和应用程序更新之间的延迟时间。

然而，每次代码更改都会触发所有导入它的 bundle 文件的重建。这在 bundle 文件大小上具有线性时间复杂度。因此，在大型应用程序中，热模块替换可能因为重建成本的增长而变得缓慢。

当前由 Vite 推崇的无打包范式（no-bundle paradigm），通过不在开发服务器中打包来应对这一问题。取而代之的是 Vite 将 ESM 模块，每个模块对应一个源文件，直接服务于浏览器。在这种范式下，每次代码更改都会触发前端单个模块的替换。这使得相对于应用程序大小，刷新时间复杂度几乎保持不变。然而，如果你有许多模块，初始页面加载可能会更长。

单一代码库（Monorepos）

在有多个团队或多个应用程序的组织中，前端可能分成多个 JavaScript 包，但保持在一个代码库中。在这样的架构中，每个包都有自己的构建步骤，它们一起形成一个包的依赖图。应用程序位于依赖图的根部。

Monorepo 工具协调依赖图的构建。它们通常提供增量重建、并行处理和远程缓存等特性。借助这些特性，大型代码库可以享受小型代码库的构建时间。

业界标准的更广泛的 monorepo 工具，如 Bazel，支持广泛的语言、复杂的构建图（complicated build graphs）和透明的执行（hermetic execution）。然而，JavaScript 对前端来说是最难完全集成到这些工具中的生态系统之一，目前几乎没有现成的案例。

幸运的是，存在专门为前端设计的若干 monorepo 工具。不幸的是，它们缺乏 Bazel 等工具的灵活性和稳健性，尤其是透明执行。

目前常用的前端特定 monorepo 工具是 Nx 和 Turborepo。Nx 更成熟且功能更强，而 Turborepo 是 Vercel 生态系统的一部分。过去，Lerna 是将多个 JavaScript 包链接在一起并发布到 NPM 的标准工具。2022 年，Nx 团队接管了 Lerna，现在 Lerna 在内部使用 Nx 来驱动构建。

另有：Bit

趋势

新的构建工具是用编译语言编写的，强调性能。2019 年的前端构建速度非常慢，但现代工具已经大大加快了速度。然而，现代工具功能集较小，有时与库不兼容，因此旧代码库通常无法轻易切换到它们。

服务器端渲染 (SSR) 在 Next.js 兴起后变得更加流行。SSR 并不会给前端构建系统带来任何根本性的不同。SSR 应用程序也必须向浏览器提供 JavaScript，因此它们执行相同的构建步骤。

toolchain

State of JavaScript 2024 构建工具: https://2024.stateofjs.com/zh-Hans/libraries/build_tools/

非原文部分

Webpack: bundler, dev_server
Parcel: dev_server
Rollup: bundler
Vite: dev_server
Prettier: formatter
ESLint: linter
Babel: transformer
terser: minifier
PostCSS: css
- cssnano: minifier
UglifyJS: minifier
Esbuild: transformer, bundler, minifier
swc: transformer, bundler, minifier
Biome: formatter, linter
Oxc: parser, linter, transformer, formatter, minifier
- Rolldown bundler
dprint: formatter
Lightning CSS: css
Rspack: webpack
Rsbuild: dev_server
Farm: vite
Mako: bundler

←Back to home

This work is licensed under CC BY-NC-SA 4.0