知海

为什么选择 Vite

vite-main开始与简介

为什么选择 Vite

随着 Web 应用的规模和复杂性不断增长，用于构建它们的工具已经难以跟上步伐。从事大型项目的开发人员都曾经历过令人痛苦的缓慢开发服务器启动、迟钝的热更新以及漫长的生产构建时间。每一代构建工具都比上一代有所改进，但这些问题始终存在。

Vite 就是为了解决这些问题而创建的。它没有在现有方法上修修补补，而是重新思考了开发期间代码的提供方式。此后，Vite 经历了多个主要版本的演进，每次都适应了生态系统中新的能力：从利用浏览器原生 ES 模块，到采用完全由 Rust 驱动的工具链。

如今，Vite 为许多框架和工具提供支持。它的架构旨在与 Web 平台共同演进，而不是固守于某一种单一方法，这使它成为一个可供您长期构建的基础设施。

起源

在 Vite 诞生之初，浏览器刚刚开始广泛支持 ES 模块（ESM），这是一种无需构建工具预先将所有文件打包成一个文件，即可直接加载 JavaScript 文件的方式。传统的构建工具（通常称为 打包器）需要在浏览器中显示任何内容之前，预先处理您的整个应用程序。应用越大，您等待的时间就越长。

Vite 采取了不同的方法。它将工作分为两部分：

  • 依赖（很少更改的库）使用快速的原生工具预先打包一次，因此它们可以立即就绪。
  • 源代码（您经常更改的应用程序代码）则通过原生 ESM 按需提供。浏览器只加载当前页面所需的内容，Vite 会在每个文件被请求时对其进行转换。

这意味着无论应用程序大小如何，开发服务器的启动几乎是即时的。当您编辑一个文件时，Vite 会利用基于原生 ESM 的热模块替换（HMR）在浏览器中只更新该模块，而无需重新加载整个页面或等待重新构建。

在基于打包的开发服务器中，整个应用程序在提供服务之前就已经完成打包。

在基于 ESM 的开发服务器中，模块会随着浏览器的请求而按需提供服务。

Vite 并非探索这种方法的第一个工具。Snowpack 开创了非打包式开发，并启发了 Vite 的依赖预打包。Preact 团队的 WMR 启发了在开发和生产环境中均可工作的通用插件 API。@web/dev-server 影响了 Vite 1.0 的服务器架构。Vite 在这些想法的基础上发展并将其发扬光大。

尽管非打包式 ESM 在开发环境中运行良好，但由于嵌套导入会产生额外的网络往返，在生产环境中直接使用它仍然效率低下。这就是打包仍然必不可少的原因，以确保生产构建得到优化。

与生态共同成长

随着 Vite 的成熟，许多框架开始采用它作为其构建层。其基于 Rollup 约定的插件 API 使得集成变得自然而然，无需框架绕开 Vite 的内部机制。Nuxt、SvelteKit、Astro、React Router、Analog、SolidStart 等框架都选择 Vite 作为它们的基础。像 Vitest 和 Storybook 这样的工具也构建在 Vite 之上，将 Vite 的应用范围扩展到了应用打包之外。像 Laravel 和 Ruby on Rails 这样的后端框架也集成了 Vite 用于它们的前端资源管道。

这种增长不是单向的。生态系统对 Vite 的塑造与 Vite 对生态系统的塑造一样多。Vite 团队运营着 vite-ecosystem-ci，它对每一个 Vite 的更改都会测试主要的生态系统项目。生态系统的健康状况并非事后才考虑的问题，它本身就是发布流程的一部分。

统一的工具链

Vite 最初依赖两个独立的工具：开发时使用 esbuild 进行快速编译，生产构建时使用 Rollup 进行全面优化。这确实有效，但维护两条流水线带来了不一致性：不同的转换行为、分离的插件系统，以及为了保持它们对齐而不断增长的粘合代码。

Rolldown 的构建就是为了将这两者统一到一个打包器中：使用 Rust 编写以获得原生速度，并兼容生态系统已经依赖的插件 API。它使用 Oxc 进行解析、转换和压缩。这为 Vite 提供了一个端到端的工具链，构建工具、打包器和编译器一起维护，并作为一个整体演进。

最终的结果是开发到生产环境的一条统一流水线。这次迁移是谨慎进行的：首先发布了技术预览版，让早期采用者能够验证这一更改；生态系统 CI 及早发现了兼容性问题；一个兼容层保留了现有的配置。

Vite 走向何方

Vite 的架构在不断发展。有几个努力方向正在塑造它的未来：

  • 完整打包模式：非打包式 ESM 在 Vite 诞生时是正确的权衡，因为当时没有工具能在开发期间实现打包所需的足够速度以及 HMR 和插件能力。Rolldown 改变了这一点。由于极为庞大的代码库可能因大量非打包网络请求而经历缓慢的页面加载，团队正在探索一种开发服务器像生产构建一样打包代码的模式，以减少网络开销。

  • 环境 API：环境 API 不再将“客户端”和“SSR”视为仅有的两个构建目标，而是让框架可以定义自定义环境（边缘运行时、Service Worker 和其他部署目标），每个环境都有自己的模块解析和执行规则。随着代码运行环境和方式的不断多样化，Vite 的模型也随之扩展。

  • 与 JavaScript 共同演进：随着 Oxc 和 Rolldown 与 Vite 的紧密合作，新的语言特性和标准可以迅速在整个工具链中被采用，而无需等待上游依赖的更新。

Vite 的目标并非成为最终的工具，而是成为一个与 Web 平台以及在其上构建的开发者共同持续演进的基础设施。

帮助我们改进文档

发现翻译问题或内容错误？请告诉我们。