问题

在 ES 模块在浏览器中可用之前，开发人员没有以模块化方式编写 JavaScript 的本机机制。这就是为什么我们都熟悉"捆绑"的概念：使用工具将我们的源模块抓取，处理和连接成可以在浏览器中运行的文件。

随着时间的推移，我们已经看到了像webpack，Rollup和Parcel这样的工具，它们极大地改善了前端开发人员的开发体验。

然而，随着我们构建越来越雄心勃勃的应用程序，我们正在处理的 JavaScript 数量也在急剧增加。大型项目包含数千个模块的情况并不少见。我们开始遇到基于 JavaScript 的工具的性能瓶颈：通常需要不合理的长时间等待（有时长达几分钟！）才能启动开发服务器，即使使用热模块替换（HMR），文件编辑也可能需要几秒钟才能反映在浏览器中。缓慢的反馈循环会极大地影响开发人员的工作效率和幸福感。

Vite 旨在通过利用生态系统中的新进展来解决这些问题：浏览器中本机 ES 模块的可用性，以及用编译为本机语言编写的 JavaScript 工具的兴起。

服务器启动缓慢

冷启动开发服务器时，基于捆绑程序的构建设置必须热切地抓取并构建整个应用程序，然后才能提供该应用程序。

Vite 通过首先将应用程序中的模块分为两类：依赖项和源代码，从而缩短了开发服务器的启动时间。

• 依赖关系大多是普通的 JavaScript，在开发过程中不经常更改。一些大型依赖项（例如，具有数百个模块的组件库）的处理成本也非常高。依赖项也可以以各种模块格式提供（例如 ESM 或 CommonJS）。

• Vite 使用 esbuild [预捆绑依赖项]。esbuild 是用 Go 编写的，预捆绑依赖项比基于 JavaScript 的捆绑器快 10-100 倍。

• 源代码通常包含需要转换的非纯 JavaScript（例如 JSX，CSS 或 Vue / Svelte 组件），并且将经常编辑。此外，并非所有源代码都需要同时加载（例如，使用基于路由的代码拆分）。

• Vite 通过本机 ESM 提供源代码。这实质上是让浏览器接管了捆绑器的部分工作：Vite 只需要在浏览器请求时按需转换和提供源代码。只有在当前屏幕上实际使用时，才会处理条件动态导入背后的代码。

基于捆绑包的开发服务器进入···路线路线模块模块模块模块···捆服务器就绪

基于本机 ESM 的开发服务器进入···路线路线模块模块模块模块···服务器就绪动态导入（代码拆分点）HTTP 请求

更新缓慢

在基于 bundler 的构建设置中编辑文件时，由于显而易见的原因，重新构建整个捆绑包是低效的：更新速度将随着应用的大小而线性下降。

在某些捆绑程序中，开发服务器在内存中运行捆绑，以便它只需要在文件更改时使其模块图的一部分失效，但它仍然需要重新构造整个捆绑包并重新加载网页。重建捆绑包可能代价高昂，重新加载页面会破坏应用程序的当前状态。这就是为什么一些捆绑器支持热模块更换（HMR）：允许模块在不影响页面其余部分的情况下"热替换"自身。这极大地改善了 DX - 但是，在实践中，我们发现，随着应用程序大小的增长，即使 HMR 更新速度也会显着下降。

在 Vite 中，HMR 通过本机 ESM 执行。编辑文件时，Vite 只需要精确地使编辑后的模块与其最近的 HMR 边界之间的链无效（大多数时候只有模块本身），无论应用程序的大小如何，HMR 更新都能始终如一地快速。

Vite 还利用 HTTP 标头来加快整页重新加载的速度（再次，让浏览器为我们做更多的工作）：源代码模块请求是通过 条件的，并且依赖模块请求通过强烈缓存，因此它们在缓存后不会再次命中服务器。304 Not Modified``Cache-Control: max-age=31536000,immutable

一旦你体验到 Vite 的速度有多快，我们非常怀疑你是否愿意再次忍受捆绑开发。

为什么要捆绑生产

尽管原生 ESM 现在已得到广泛支持，但由于嵌套导入导致额外的网络往返，在生产环境中交付未捆绑的 ESM 仍然效率低下（即使使用 HTTP/2）。为了在生产环境中获得最佳的加载性能，最好将代码与树抖动，延迟加载和常见的块拆分（以获得更好的缓存）捆绑在一起。

确保开发服务器和生产版本之间的最佳输出和行为一致性并非易事。这就是为什么 Vite 附带了一个预配置的构建命令，该命令开箱即用地烘焙了许多性能优化。

为什么不与 esbuild 捆绑在一起？

虽然速度非常快，并且已经是一个非常强大的库捆绑器，但捆绑应用程序所需的一些重要功能仍在进行中 - 特别是代码拆分和 CSS 处理。目前，Rollup 在这些方面更加成熟和灵活。也就是说，我们不会排除将来在稳定这些功能时将其用于生产构建的可能性。esbuild``esbuild

Vite 与 X 有何不同？

WMR

Preact 团队的WMR提供了类似的功能集，Vite 2.0 对 Rollup 插件接口的支持也受到了它的启发。

WMR 主要为Preact项目而设计，并提供更多集成功能，例如预渲染。就范围而言，它更接近 Preact 元框架，与 Preact 本身一样强调紧凑的大小。如果您使用的是 Preact，WMR 可能会提供更精细的体验。

@web/开发服务器

@web/dev-server（以前）是一个伟大的项目，Vite 1.0 基于 Koa 的服务器设置受到它的启发。es-dev-server

@web/dev-server在范围方面有点低。它不提供官方框架集成，并且需要手动为生产版本设置汇总配置。

总体而言，Vite 是一个更固执己见/更高级的工具，旨在提供更开箱即用的工作流程。也就是说，伞形项目包含许多其他出色的工具，这些工具也可能使 Vite 用户受益。@web

Snowpack

Snowpack也是一个无捆绑的原生 ESM 开发服务器，在范围上与 Vite 非常相似。该项目不再维护。Snowpack 团队现在正在开发Astro，这是一个由 Vite 提供支持的静态网站构建器。Astro 团队现在是生态系统中的活跃参与者，他们正在帮助改进 Vite。

除了不同的实现细节外，这两个项目在技术上比传统工具具有很多共同的优势。Vite 的依赖性预捆绑也受到 Snowpack v1（现已安装）的启发。

开始

概述

Vite（法语单词“quick”，发音为“veet”）是一个构建工具，旨在为现代 Web 项目提供更快，更精简的开发体验。它由两个主要部分组成：/vit/

• 一种开发服务器，它提供比本机 ES 模块[更丰富的功能增强]，例如极快的热模块更换 （HMR）。

• 一种生成命令，用于将代码与汇总捆绑在一起，该命令已预先配置为输出用于生产的高度优化的静态资产。

Vite 固执己见，并带有开箱即用的合理默认值，但也可以通过其插件 API 和具有完全类型支持的[JavaScript API]进行高度扩展。

浏览器支持

默认生成面向支持本机 ES 模块、本机 ESM 动态导入和导入的浏览器。元。旧版浏览器可以通过官方 @vitejs/plugin-legacy 提供支持 - 有关更多详细信息，请参阅[生产构建]部分。

尝试在线体验维特

您可以在[StackBlitz]上在线试用 Vite。它直接在浏览器中运行基于 Vite 的构建设置，因此它几乎与本地设置相同，但不需要在计算机上安装任何内容。您可以导航到 以选择要使用的框架。vite.new/{template}

支持的模板预设包括：

搭建您的第一个 Vite 项目

兼容性说明

Vite 需要 Node.js 版本 14.18+、16+。但是，某些模板需要更高的 Node.js 版本才能工作，如果您的包管理器发出警告，请升级。

使用 NPM：

$ npm create vite@latest

使用 Yarn：

$ yarn create vite

使用 PNPM：

$ pnpm create vite

然后按照提示操作！

还可以通过其他命令行选项直接指定项目名称和要使用的模板。例如，要构建 Vite + Vue 项目的基架，请运行：

# npm 6.xnpm create vite@latest my-vue-app --template vue
# npm 7+, extra double-dash is needed:npm create vite@latest my-vue-app -- --template vue
# yarnyarn create vite my-vue-app --template vue
# pnpmpnpm create vite my-vue-app --template vue

有关每个受支持模板的更多详细信息，请参阅 create-vite：、 、 。vanilla``vanilla-ts``vue``vue-ts``react``react-ts``preact``preact-ts``lit``lit-ts``svelte``svelte-ts

社区模板

create-vite 是一种工具，可以从流行框架的基本模板快速启动项目。查看 Awesome Vite，了解包含其他工具或针对不同框架[的社区维护模板]。您可以使用像degit这样的工具，通过其中一个模板来构建项目的基架。

npx degit user/project my-projectcd my-project
npm installnpm run dev

如果项目用作默认分支，则在项目存储库后添加后缀main``#main

npx degit user/project#main my-project

index.html和 project root

您可能已经注意到的一件事是，在 Vite 项目中，它是前端和中央的，而不是隐藏在里面 。这是有意为之：在开发过程中，Vite 是一个服务器，是应用程序的入口点。index.html``public``index.html

Vite 将其视为源代码和模块图的一部分。它解析引用您的 JavaScript 源代码。即使是内联和通过引用的 CSS 也享受 Vite 特定的功能。此外，内部的 URL 会自动重新定位，因此不需要特殊的占位符。index.html``<script type="module" src="...">``<script type="module">``<link href>``index.html``%PUBLIC_URL%

与静态 http 服务器类似，Vite 具有“根目录”的概念，您的文件就是从中提供的。您将看到它被引用，就像在文档的其余部分一样。源代码中的绝对 URL 将使用项目根目录作为基础进行解析，因此您可以编写代码，就好像您正在使用普通的静态文件服务器一样（除了更强大的方式！Vite 还能够处理解析到根外文件系统位置的依赖项，这使得它即使在基于 monorepo 的设置中也可以使用。<root>

Vite 还支持具有多个入口点的多页应用程序。.html

指定备用根目录

运行将使用当前工作目录作为 root 启动开发服务器。可以使用 指定备用根目录。vite``vite serve some/sub/dir

命令行界面

在安装了 Vite 的项目中，可以在 npm 脚本中使用二进制文件，也可以使用 直接运行它。以下是基架 Vite 项目中的默认 npm 脚本：vite``npx vite

{  "scripts": {    "dev": "vite", // start dev server, aliases: `vite dev`, `vite serve`    "build": "vite build", // build for production    "preview": "vite preview" // locally preview production build  }}

您可以指定其他 CLI 选项，如 或 。有关 CLI 选项的完整列表，请在项目中运行。--port``--https``npx vite --help

使用未释放的提交

如果您迫不及待地等待新版本来测试最新功能，则需要将 vite 存储库克隆到本地计算机，然后自行构建并链接它（需要 pnpm）：

git clone https://github.com/vitejs/vite.gitcd vitepnpm installcd packages/vitepnpm run buildpnpm link --global # you can use your preferred package manager for this step

然后转到基于 Vite 的项目并运行（或用于全局链接的包管理器）。现在重新启动开发服务器，骑在最前沿！pnpm link --global vite``vite