vite 迁徙记录
为什么要迁徙到 vite
当咱们开始构建越来越大型的利用时,须要解决的 JavaScript 代码量也呈指数级增长。蕴含数千个模块的大型项目相当广泛。基于 JavaScript 开发的工具就会开始遇到性能瓶颈:通常须要很长时间(甚至是几分钟!)能力启动开发服务器,即便应用模块热替换(HMR),文件批改后的成果也须要几秒钟能力在浏览器中反映进去。如此周而复始,机灵的反馈会极大地影响开发者的开发效率和幸福感。
为了进步开发的幸福感和愉悦度,和进步开发效率的状况下,最近对一个我的项目进行了革新迁徙,迁徙实现后热更速度让我有了十分舒畅的感觉。
vite 为什么这么快
在冷启动的时候,基于打包器的形式启动必须优先抓取并构建你的整个利用,而后能力提供服务。然而 vite 通过在一开始将利用中的模块辨别为 依赖
和 源码
两类。
-
依赖
大多为在开发时不会变动的纯 JavaScript。一些较大的依赖(例如有上百个模块的组件库)解决的代价也很高。依赖也通常会存在多种模块化格局(例如 ESM 或者 CommonJS)。Vite 将会应用 esbuild 预构建依赖。esbuild 应用 Go 编写,并且比以 JavaScript 编写的打包器预构建依赖快 10-100 倍。
源码
通常蕴含一些并非间接是 JavaScript 的文件,须要转换(例如 JSX,CSS 或者 Vue 组件),时常会被编辑。同时,并不是所有的源码都须要同时被加载(例如基于路由拆分的代码模块)。
Vite 以 原生 ESM 形式提供源码。这实际上是让浏览器接管了打包程序的局部工作:Vite 只须要在浏览器申请源码时进行转换并按需提供源码。依据情景动静导入代码,即只在以后屏幕上理论应用时才会被解决。
Webpack 式的经典 bundler 示意图
Vite 式的 No-bundler 示意图
Vite 能兼容 IE 吗
应用官网插件 @vitejs/plugin-legacy 反对
环境要求是什么
最低要求 Node14.18.0+
开始迁徙
必备插件
- 必要的依赖:
vite-plugin-html
,vite
, - Vue 3 单文件组件反对:
@vitejs/plugin-vue
- Vue 3 JSX 反对:
@vitejs/plugin-vue-jsx
- Vue 2.7 反对:
vitejs/vite-plugin-vue2
- Vue <2.7 的反对:
underfin/vite-plugin-vue2
Eslint 集成
咱们在 awesome-vite
库中可能会看到两个 Eslint 插件,那么他们有什么不同呢?
在这里了举荐应用@nabla/vite-plugin-eslint
,为什么呢?
相较于vite-plugin-eslint
,下面举荐的能够放弃 HMR 迅速,因为 linting 是异步实现的,不会阻塞编译的进行,而这个插件会先查看 linting 再编译,这样咱们的 HMR 就变慢了。
环境变量辨别
Vite 应用 dotenv 从你的 环境目录 中的下列文件加载额定的环境变量:
.env # 所有状况下都会加载
.env.local # 所有状况下都会加载,但会被 git 疏忽
.env.[mode] # 只在指定模式下加载
.env.[mode].local # 只在指定模式下加载,但会被 git 疏忽
mode 是怎么配置的,能够在启动 vite 的时候增加 –mode ${你的 mode}
遇到的问题
咱们应用了非阻塞的 eslint 会导致构建抛出的告警不终止构建,这个时候就能够在构建前进行手动 eslint 查看
with 语法的问题
在 vite 启动构建依赖的时候 esbuild 会呈现 with 语法不能兼容的状况,这个时候这个包只能通过应用 js 去申请一个 script 的办法来躲避
npm 的包没有指定入口文件
因为 vite 解析须要依赖入口文件,在没有配置的状况下,须要在引入的时候须要指定到具体的文件
其余注意事项
-
应用 CommonJS 标准语法,例如 require(‘**’);
-
1. 请转换为 ESM 语法
- 2. 应用 Web API new URL
-
![img_3.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1987892252d444f1a97f969a5daf34d6~tplv-k3u1fbpfcp-watermark.image?)
-
蕴含多个别名的导入,如:
@import '~@/styles/global.scss'
,同时蕴含了别名 ~ 和 @- 您能够增加别名配置
{find: /^~@/, replacement: path.resolve(__dirname, 'src') }
到resolve.alias
配置中,并且把该项配置移到别名配置中的第一项
- 您能够增加别名配置
-
对于 Webpack 语法 require.context
- 在 vite 中应用 import.meta.glob 替换
-
Webpack 全局变量变更
-
应用 define 配置选项
-
-
全局环境变量变更
- process.env 应用 import.meta.env 代替
-
装新依赖包后重启发现还是旧的包
-
须要应用 force 进行重启
-
构建生产版本
浏览器兼容性
Vite 的默认指标是反对原生 ESM 和 import.meta 的浏览器,chrome> 87, 这个状况下很显然是不能满足咱们的,咱们须要配置一个 build.target 进行扭转兼容性,因为 vite 的转换过程是由 esbuild 进行的,那么只须要查看一下 esbuild 的选项,比方我当初迁徙的我的项目是要反对 WebRTC 的,那么我只须要配置一个
build: {target: 'chrome55'}
这样就会转换到兼容的选项了
原理解析
npm 包依赖解析的预构建
在浏览器中原生 ES 导入不反对上面这样的裸模块导入,
import {someMethod} from 'my-dep'
下面的代码会在浏览器中抛出一个谬误。因为浏览器是找到 my-dep 的门路的,所以 Vite 将会检测到所有被加载的源文件中的此类裸模块导入,并执行以下操作:
- 预构建 它们能够进步页面加载速度,并将 CommonJS / UMD 转换为 ESM 格局。预构建这一步由 esbuild 执行,这使得 Vite 的冷启动工夫比任何基于 JavaScript 的打包器都要快得多。
- 重写导入为非法的 URL,例如 /node_modules/.vite/deps/my-dep.js?v=f3sf2ebd 以便浏览器可能正确导入它们。
模块热替换
Vite 的热更新原理,其实就是在浏览器与 vite 服务端建设了一个 websocket 连贯,服务端监听代码变动,当代码被批改后,服务端发送 socket 音讯告诉客户端去申请批改模块的代码,实现热更新。
TypeScript
Vite 应用 esbuild 将 TypeScript 转译到 JavaScript,约是 tsc 速度的 20~30 倍,同时 HMR 更新反映到浏览器的工夫小于 50ms。
速度比照
启动速度比照
我的项目 | vite | webpack |
---|---|---|
冷启动 | 4.895s | 1:38.585 s |
热启动 | 2.289s |
vite 热启动工夫
webpack 启动速度工夫
构建速度比照
我的项目 | vite | webpack |
---|---|---|
带 sourceMap | 59.66s | 3:24.553s |
不带 sourceMap | 42.09s | 1:27.630s |
能够看到构建的速度是大幅度的缩短了的
vite 带 sourceMap 工夫
vite 不带 sourceMap 工夫
webpack 带 sourceMap 工夫
webpack 不带 sourceMap 工夫
想要 npm link 进行 vite 调试?
在开发的时候难免会有一些须要本地调试的一些包,那么咱们应该如何进行配置呢,如果是 CJS 的包,倡议应用 ESM 的来进行调试,不然只能用 --force
进行重启。如果应用的是 webpakck,倡议降级到 Webpack5,配置 moudule 的输入,详情能够查看 webpack 的文档进行配置。
配置 ESM 的 npm link
咱们首先要晓得 npm link 的原理是配置一个软连贯指向另外一个目录,那么咱们要让 vite 不对这个包进行依赖预构建,这个时候就要配置 optimizeDeps
的exclude
属性,增加对应的 npm 包,而后通过 --force
进行重启,这个时候你只有改被依赖的包,vite 就会主动帮你刷新。浏览器中的 network 也要记得禁用缓存哦。
现存的问题
文件多的时候,第一次须要预编译的文件很多而且申请十分多,这样会导致第一次启动的白屏工夫过长,这里有两个计划能够解决。
- 能够启用 h2,这样就不会被限度为 h1.1 的 6 个申请。
- 能够配置 warmup,让启动的时候就间接预处理所有文件。
好的插件举荐
插件合集
免去 https 证书告警
文件预热
这个插件能够让你启动 vite 后立即进行文件预热,不须要等到申请后再编译,能够无效缩小白屏工夫
总结
这次迁徙上线并没有发现什么异样。总体来说,当初 vite 曾经比拟成熟了,在商用我的项目上曾经能够胜任了。而且构建和热更速度有了质的飞跃。