在以后，应用领域程序中没组件化的结构设计，他们须要把大部份源标识符校对到两个 js 文档中提供更多给应用领域程序采用，因此在合作开发中他们运转开启指示的这时候， webpack 须要从出口处文档去检索整座工程项目的文档，校对成两个或多个原则上的 js 文档。即便选用了标识符分拆，或许要一场聚合大部份路由器下的校对后文档。这就引致了服务项目开启天数随著工程项目维数而指数级快速增长。
Vite 所提倡的no-bundle经营理念的或者说涵义是借助应用领域程序原生植物 ES 组件的全力支持，同时实现测试阶段的 Dev Server，展开组件标识符的按需读取。应用领域程序允诺相关联的 url 的这时候，提供更多相关联的文档，两个 import 句子代表者两个 HTTP 允诺。
这儿说的组件标识符只不过分为两部份：
一小部份是源标识符，即销售业务标识符，另一小部份是服务项目器端倚赖的标识符，即node_modules中的标识符。简而言之的no-bundle而已对源标识符来说，对服务项目器端倚赖来说，Vite 会展开倚赖的预构筑。
预构建
因此为何在测试阶段他们要对服务项目器端倚赖展开预构筑? 假如不展开预构筑会好不好？
具体来说 Vite 是如前所述应用领域程序原生植物 ESM 组件规范化同时实现的 Dev Server，无论是应用领域标识符，却是服务项目器端倚赖的标识符，理应符合 ESM 规范化才能恒定运转。但现阶段除了相当多的服务项目器端库依然没 ES 版的乙醛，比如说赫赫有名的react
这种 CommonJS 文件格式的标识符在 Vite 当中无法直接运转，他们须要将它转换成 ESM 文件格式的乙醛。
另外第三方倚赖每个库中也会有大量的文档允诺，在这种倚赖层级深、涉及组件数量多的情况下，会触发成百上千个网络允诺，引致页面读取缓慢。因此须要把服务项目器端标识符打包成两个bundle
即预构筑主要做了两件事情：
把大部份的 CommonJS 转换为 ESM 文件格式把 dependency 转换成单个组件，即打包服务项目器端库的标识符，将各个服务项目器端库分散的文档合并到一起，减少 HTTP 允诺数量，而这两件事情全部由性能优异的Esbuild(如前所述 Golang 合作开发)完成，这也是 Vite 工程项目开启飞快的两个核心原因。
而且 esbuild 还会对部份文档如 tsx 展开类型解析，将其转换成应用领域程序可以识别的语法的。Vite 在接受到应用领域程序发送的 http 允诺之后会去校对相应的文档，提供更多给应用领域程序。这样会有两个合理的疑问，速度够吗？
够！esbuild 非常快！
Vite 功能
组件热重载
Vite 全力支持 Vue 和 React 的组件热重载，可以准确的更新页面而无需重新读取页面或者删除应用领域程序状态
TypeScript
Vite 全力支持开箱即用的引入 .ts 文档，但值得注意的是 Vite 仅执行 ts 文档的翻译工作，并不执行任何类型检查，这是因为 Vite 采用 esbuild 展开转译工作，而并不含类型信息，因此不全力支持 TypeScript 的特定功能如「常量枚举」「隐式 type-only 导入」。你必须在你的 tsconfig.json 中的 compilerOptions 里设置 “isolatedModules”: true，这样 TS 才会警告你哪些功能无法与独立校对模式一同工作。
