背景
为什么选用vite,其实就是为了解决官网说的2个原因
- 缓慢的服务器启动
- 缓慢的更新
风险分析
- 为什么不用vue3?
业务系统涉及到的生产环境需要兼容ie11,很明显vue3不会支持,同时vue2迁移起来成本较小
- vite对ie11的兼容性支持
官网有 @vitejs/plugin-legacy
支持传统浏览器
- 社区支持
社区已经有vue2+vite的例子,可以直接调试,减低学习成本
vite-vue2-simple-starter
- 迁移成本
由于是尝鲜,因此先迁移子系统,把坑都踩了,方便后面深入优化
搭建前端项目模板
首要目标是把构建vite环境,毕竟80%的业务代码都可以复用。
- 改造前: 冷启动 30s左右
- 改造后: 冷启动 6s 左右
遇到问题
- process is not defined
在vite项目中只能访问process.env.NODE_ENV
变量,访问process.env.xxx其他无效,会导致报错。
Vite 在一个特殊的 import.meta.env 对象上暴露环境变量。
import.meta.env.xxx
import.meta.env.MODE: {string} 应用运行的模式。
import.meta.env.BASE_URL: {string} 部署应用时的基本 URL。他由base配置项决定。
import.meta.env.PROD: {boolean} 应用是否运行在生产环境。
import.meta.env.DEV: {boolean} 应用是否运行在开发环境 (永远与 import.meta.env.PROD相反)。
import.meta.env.SSR: {boolean} 应用是否运行在 server 上。
vite如何设置自定义变量?
Vite内置了dotenv这个第三方库, dotenv会自动读取.env文件, dotenv 从你的 环境目录 中的下列文件加载额外的环境变量:
.env # 所有情况下都会加载
.env.[mode] # 只在指定模式下加载
加载的环境变量也会通过import.meta.env
以字符串形式暴露给客户端源码。为了防止意外地将一些环境变量泄漏到客户端,只有以VITE_为前缀的变量才会暴露给经过vit
处理的代码。
.env
文件示例:
VITE_FOO=1
- 不支持webpack
~
写法,主要体现在style下的css的资源引入路径
这是属于webpack的写法,以~
开头的url,其后的任何内容都会作为一个模块请求被解析,即使是相对路径。
直接把~
去掉即可,或者保留~
,修改vite.config.js
配置:
export default defineConfig({
// ...
resolve: {
alias: [
{ find: /^~/, replacement: '' }
],
}
});
具体更多细节可以参考issue-2185
- vite 跨域
module.export = function() {
server: {
host: HOST,
port: process.env.PORT,
proxy: {
'/api': {
target: 'http://1270.0.1:9999',
changeOrigin: true,
rewrite: path => path.replace(/^\/api/, '')
}
}
},
}
import
无法正确识别没有添加.vue
后缀
import xxx from "xxxx"
- vite如何使用jquery
npm i @rollup/plugin-inject -D
vite.config.js
export default defineConfig({
...
plugin: [
inject({
$: "jquery", // 这里会自动载入 node_modules 中的 jquery jquery全局变量
jQuery: "jquery",
"windows.jQuery": "jquery"
})
],
...
})
- less热更新不生效
重启即可
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。