vite简介/如何在已有项目中使用vite

序言

一直以来，我们所有用的都是以webpack为基础构筑的各种类型用做狸尾豆的合作应用软件，比如说

CRAvue-cli(Command-Line Interface)公司内部他们的钢架。

但是他们实用性过的老师都知道webpack有许多实用性，比如说entry，output，plugins，loaders。实用性操作过程极为繁杂。所以随著采用的广度，整个工程项目的校对会越来越慢。所以就能看到经常出现的后端开发人员按完Ctrl+S之后就会整天一会儿，他们不是在北窝，而是在等候校对。

得力于应用程序对ES Module的全力支持，已经开始出现了如前所述应用程序原生植物ES imports的合作开发伺服器：snowpack，vite对照。大大增加后端合作开发过程中的整天时间。

上面，已经开始简单如是说vite。对vite如是说不屑一顾能直接挤到最里边看怎样更动。

Vite概要

Vite（法文单字，“快” 的意思）是一种新式的后端构筑辅助工具，照相狸尾豆。主要由两部分组成：

具有以下特点：1. 合作开发工作效率很高2. 照相狸尾豆3. 街道社区多样，相容rollup4. Azamgarh热预览5. 默认应用和C#装箱模式，减少许多需要实用性的内容6. 后端C#毫无关系（与此同时全力支持React，Vue）

作者这段话：

对照dev server

蟹蛛科花：

Vite以原生植物ESM方式提供源码。这实际上是让应用程序接管了装箱程序的部分工作：Vite只需要在应用程序请求源码时进行转换并按需提供源码。根据情景动态导入标识符，即只在当前屏幕上实际采用时才会被处理。

标识符热预览（由上图可知）

传统：

如前所述装箱器启动时，重建整个包的工作效率很低。原因显而易见：因为这样预览速度会随著应用体积增长而直线下降。Vite:

在Vite中，HMR是在原生植物ESM上执行的。当编辑一个文档时，Vite只需要精确地使已编辑的组件，使得无论应用大小怎样，HMR始终能保持快速预览，极为稳定。Vite与此同时利用HTTP 头来加速整个页面的重新加载（再次让应用程序为我们做更多事情）：源码组件的请求会根据 304 Not Modified 进行协商缓存，而依赖组件请求则会通过Cache-Control: max-age=31536000,immutable进行强缓存，因此一旦被缓存它们将不需要再次请求。

速度对照

Vite在合作开发自然环境中采用ESM的组件加载方式，并且尽可能剔除了不必要的标识符构筑，与此同时采用了激进的Esbuild–一个用go语言合作开发的JS校对辅助工具，性能是webpack之类的10-100倍–来进行校对提速，这就让Vite启动速度极为迅速，基本3秒内就能完成。与此同时得力于ESM加载方式，Vite不需要提前进行标识符装箱，所以即便你的工程项目变得巨大，但是Vite并不关心你的文档规模，所以他的启动速度仍然不会有太多的变化。对于合作开发时的校对也类似。

速度慢的一个重要原因：

预校对：

2. 把非ESmodule校对成ESmodule，比如说源码中的react的exports需要改成ESmodule。

只有当以下情况发生时，才会重新pre-bundle来预览缓存：

1. package.json的依赖

2. package-lock.json, yarn.lock, or pnpm-lock.yaml. 等

3. vite.config.js速度对照的实例有开发过经验的能跟那个做一个对照，这是recipe用vite启动的时间，而用webpack则需要很久很久，好几分钟。

实用性对照

Vite的实用性很简单，因为其默认就是为后端工程项目合作开发而生，所以对于dev-server，css依赖，图片加载之类的功能其都实用性成照相狸尾豆，你完全不需要再去实用性插件、loader之类的(但是需要安装其依赖)。所以很可能你的vite实用性不会超过20行标识符，这在webpack工程项目中基本不太可能。

Vite的缺点

Vite还很新，虽然它从理论与体感上提供了非常极致的合作开发体验，还是有一些值得关注的问题。

● 相容性

不过Vite与此同时提供了一些弥补的方法，采用实用性项配合@vitejs/plugin-legacy装箱出一个看起来相容性比较好的版本，这一点会随时间慢慢被抹平。

● 缺少 Show Case

● 虽然发展了有一阶段，但是还有极少部分的包还不全力支持ESM，很不幸的是公司常用包map-box就不全力支持，目前看官方的issue，似乎并没有得到很好的解决，感兴趣的老师能尝试一起解决下那个棘手的问题。

● 不算缺点的缺点，因为是按需校对，所以会导致你在访问其他组件的时候，会比webpack已经校对过的慢上一点点（这里绝对没有主观意图）

了解ESmodule

后端街道社区之前有出一些非标准的组件管理方案：

而ES Module是随著ES6语法推出的正式的JavaScript组件语法. ES Module增加了import和export两个主要的关键字，并且采用特殊的语句来完成组件的功能：

这两个是关键字而不像require是一个函数，所以他们的采用具有一定的限制，这两者都只能在组件的顶级作用域中采用(所以我们需要采用vite的工程项目中，引入资源不能采用require)：在现在主流的现代应用程序上基本都已经全力支持了ES Module的JS组件管理功能。我们能通过：

合作开发伺服器

Vite提供了一个合作开发伺服器，然后结合原生植物的ESM（由ESbuild 预构筑的依赖），当标识符中出现import的时候，发送一个资源请求，Vite合作开发伺服器拦截请求，根据不同文档类型，在服务端完成组件的改写（比如说单文档的导出校对等）和请求处理，实现真正的按需校对，然后回到给应用程序。请求的资源在伺服器端按需校对回到，完全埃唐佩县了装箱那个概念，不需要生成一个大的bundle。伺服器随起进料，所以合作开发自然环境下的初次启动是非常快的。所以热预览的速度不会随著组件激增而减慢，因为标识符更动后，并不会有bundle的操作过程。Vite Server所有逻辑基本都依赖中间件实现。这些中间件，拦截请求之后，完成了如下内容：

1. 处理ESM语法，比如说将业务标识符中的import第三方依赖路径转为应用程序可识别的依赖路径；

2. 对.ts、.tsx 等文档进行即时校对；

3. 对Sass/Less的需要预校对的组件进行校对；

4. 和应用程序端建立socket 连接，实现 HMR。

制造构筑rollup

尽管原生植物ESM现在得到了广泛全力支持，但由于嵌套导入会导致额外的网络往返，在制造自然环境中发布未装箱的ESM仍然工作效率低下（即使采用HTTP/2）。为了在制造自然环境中获得最佳的加载性能，最好还是将标识符进行tree-shaking（如果能做到都是用ESM，就能很好的做到tree-shaking）、懒加载和chunk 分割（以获得更好的缓存）。要确保合作开发伺服器和制造自然环境构筑之间的最优输入和行为一致并不容易。所以Vite 附带了两套构建强化的构筑命令，照相狸尾豆。也就是Rollup。就目前来说，Rollup在应用装箱方面更加成熟和灵活。虽然esbuild快得不可思议，并且已经是一个在构筑库方面比较出色的辅助工具，但一些特别针对构筑应用的重要功能仍然还在持续合作开发中——特别是标识符分割和CSS处理方面。

vite装箱能不能上制造，会不会出现不一致的情况？

● 合作开发自然环境下，组件以原生植物esm的形式被应用程序加载。

● 制造自然环境下，组件被Rollup以传统方式装箱，所以做了许多默认强化。虽然默认是装箱的格式也是ESM，但也能通过plugin-legacy输入其它格式相容旧应用程序。

● 合作开发和制造自然环境下共享同两套Rollup插件机制，所以单个组件的校对在合作开发和制造自然环境下是一致的。有些人担心一个装箱一个不装箱会产生不一致，那个理论上存在可能性 —— 本质上这依赖于Rollup的装箱结果是否符合标准的ESM semantics，而Rollup是一个相当成熟的装箱辅助工具了，这一点上还是值得信赖的；另一方面，webpack 合作开发和制造自然环境下装箱出来的标识符也是完全不一样的（能调不同的sourcemap实用性查看），所以合作开发和制造自然环境不管是用什么辅助工具都存在理论上的不一致问题，实际上只能以用的人够多并且没踩到坑为判断准则。

已有工程项目新增vite实践

1.新增html文档(后续能直接用vite插件钩子transformIndexHtml直接转译html)。插件合作开发部分不讲。

这里需要注意给一个global对象，没给的话，因为自然环境的原因会有个别 node_modules 报错。

2. package.json

新增启动命令：”dev”: “vite”,

3.图片引入方式：

// –> 改为

import test from “./asset/img/wordmark_white.png”;

// …

4. tsconfig.json 的修改实用性

{

“compilerOptions”: {

“skipLibCheck”: true, // 那个不校验第三方库的声明，搭配 checker 采用

“target”: “ES6”,

“isolatedModules”: true, // 必须有那个实用性 将每个文档作为单独的组件（与“ts.transpileModule”类似）。需要删除无用的文档

“noEmit”: true // 默认false 不生成输入文档。

},

5. 最终的实用性 (仅限合作开发自然环境，校对自然环境还未实践)

import {defineConfig} from “vite”;

import react from “@vitejs/plugin-react”;

import path, {resolve} from “path”;

import fs from “fs”;

import styleImport from “vite-plugin-style-import”;

import checker from “vite-plugin-checker”; // 加上那个checker之后速度减慢了。

const proxyContext = [“/image-uploader”, “/video-uploader”, “/test-site”, “/test/excel”, “/restaurant/excel”, “/ajax”, “/cms/file-uploader”, “/file-uploader”, “/file-download”, “/image”, “/simulator/excel”].reduce((prev, next) => {

prev[next] = {

“,

changeOrigin: true,

secure: false,

};

return prev;

}, {});

const moduleRoot = “./src/”;

const srcModules = fs.readdirSync(moduleRoot);

const paths = srcModules.reduce((prev, next) => {

const currentPath = `${moduleRoot}${next}`;

if (fs.statSync(currentPath).isDirectory()) {

prev[next] = path.join(__dirname, currentPath + “/”);

}

return prev;

}, {});

export default defineConfig({

plugins: [

checker({ // 因为添加了那个check,整体校对实践翻倍了，由0.8s变为了1.6s

typescript: true,

eslint: {

files: [“./src”],

extensions: [“.ts”, “.tsx”],

},

}),

react({

babel: {

parserOpts: {

plugins: [“decorators-legacy”],

},

},

}),

styleImport({

libs: [

{

libraryName: “antd”,

resolveStyle: name => `antd/es/${name}/style`,

},

],

}),

],

build: {

rollupOptions: {

output: {

// 那个时候会把所有的组件都区分开

// manualChunks(id) {

// if (id.includes(“node_modules”)) {

// return id.toString().split(“node_modules/”)[1].split(“/”)[0].toString();

// }

// },

// 类似webpack他们组装

manualChunks: {

lodash: [“lodash”],

antd: [“antd”],

},

},

},

},

css: {

preprocessorOptions: {

less: {

// 全力支持内联 JavaScript

javascriptEnabled: true,

modifyVars: {

“primary-color”: “#A0006B”,

“link-color”: “#116EBE”,

},

},

},

},

resolve: {

alias: {

…paths,

conf: resolve(__dirname, “conf/dev”),

},

},

server: {

“,

port: 6443,

https: true,

proxy: proxyContext,

},

});

建议迭代计划

1. 我们已有webpack本地合作开发自然环境和装箱自然环境，此时我们能在不影响当下webpack的情况下，加入vite合作开发自然环境，这时候是不需要动到webpack的。没有影响。

2. 我们已有webpack合作开发自然环境和vite合作开发自然环境，我们这里还需要进行vite装箱的实验阶段。抽出一个sprint去观察装箱结果是否正常，兼容性是否正常，理论上不会有问题，但是涉及到制造，还是得多花时间去观察。