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

预构建它们能够进步页面加载速度，并将 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曾经比拟成熟了，在商用我的项目上曾经能够胜任了。而且构建和热更速度有了质的飞跃。