关于javascript:从vuecli迁移到Vite的过程

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 将会检测到所有被加载的源文件中的此类裸模块导入，并执行以下操作:

1. 预构建 它们能够进步页面加载速度，并将 CommonJS / UMD 转换为 ESM 格局。预构建这一步由 esbuild 执行，这使得 Vite 的冷启动工夫比任何基于 JavaScript 的打包器都要快得多。
2. 重写导入为非法的 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 启动速度工夫

构建速度比照

能够看到构建的速度是大幅度的缩短了的

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 也要记得禁用缓存哦。

现存的问题

文件多的时候，第一次须要预编译的文件很多而且申请十分多，这样会导致第一次启动的白屏工夫过长，这里有两个计划能够解决。

1. 能够启用 h2，这样就不会被限度为 h1.1 的 6 个申请。
2. 能够配置 warmup，让启动的时候就间接预处理所有文件。

好的插件举荐

插件合集

免去 https 证书告警

文件预热

这个插件能够让你启动 vite 后立即进行文件预热，不须要等到申请后再编译，能够无效缩小白屏工夫

总结

这次迁徙上线并没有发现什么异样。总体来说，当初 vite 曾经比拟成熟了，在商用我的项目上曾经能够胜任了。而且构建和热更速度有了质的飞跃。