本篇文章给大家谈谈vite，以及vue vite的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
文章详情介绍：
Vite 可以用在生产环境吗？亲身经历告诉你用了Vite之后，太爽了！
记录、分享IT相关知识和见闻！
想要了解更多软件相关知识的朋友！
记得右上角添加【关注】，支持一下！
最近有很多同事以及网友咨询我关于前端打包工具的使用问题！
因为说了很多遍，而且都是理论上的交流，所以写这篇文章把最近使用Vite的情况简单汇总说明一下。
就在我这篇文章之前，Vite 的4.2版本已经发布了，据说相比4.0又快了10倍！
关于Vite 的介绍以及详细配置这里就不过多说了，用过Webpack的人使用vite，可以说零成本！ 五分钟就能上手。
文章开头先回答一下大家的几个疑问：
Q: Vite 是否能够用于生产环境？
A： 必须可以，我希望你尽快使用！
Q：能否替代Webpack？
A：新项目，完全没问题，稳得很。
Q：Vite 相对于 Webpack 有什么优势？
A：三个字告诉你： 快、快、快
接下来给大家分享一下我使用这些前端构建工具的一些经历。
rollup 时代
早些时候，我们项目组使用的rollup打包，配置不算复杂，但是几乎都是手动配置！
由于流行度并不是很高，所以大概用了2个项目左右就抛弃了。
Webpack + plugin
在rollup之后，我们又将打包工具切换到webpack。
由于项目比较复杂，所以写了大量的插件；
基于这些插件，手写了各种打包命令。
就这样，这个项目越做越大，越难维护；
每次启动时，I7 的电脑大概得5分钟左右，实在太痛苦！
Webpack5
在手写插件难以拓展、难以维护的情况下！
后面去掉了自己手写的插件；
把webpack也升级到了5.0版本！
优化后的项目整体速度提高了30%左右，但是还是非常慢。
Vite 时代
在经历了一段痛苦的阶段之后！
一个非常好的消息是：另一款打包神器 Vite 诞生了！
由于天然的“本土” 化支持！
Vite 受到国内非常高的关注度！
笔者也第一时间关注并使用了它。
为什么可以说 Vite 能够正式使用在生产环境呢？
在 Vite 3.0 之前的版本，确实存在各种问题！
尤其是 vite 1.0 ，很多插件都会报错。
想用在生产环境，真的是要很大的勇气！
不过在3.0之后的版本，就改善了许多！
我就是从3.0开始正式在生产环境使用的。
从去年6月开始使用vite，我已经用vite开发了 6个项目了。
在使用vite的时候确实也遇到一些问题；
但是相比webpack遇到的问题，真的算是毛毛雨了。
正式项目 Vite 是否能够替代 Webpack
正式项目如果是新的项目，建议还是优先使用Vite来开发。
如果是旧的Webpack项目，不建议切换至Vite。
首先关于Vite 要知道，它使用的ESModule模式，开发过程中是无需打包的！
旧的Webpack项目，很多的插件库不支持，要想使用vite还得折腾一番。
另外如果你的项目依赖一些非ESModule的老旧的库，也是不建议使用Vite；
如果要用，可以先去调研一下这些库在Vite中是否能够用其他插件来支持一下。
为什么要使用Vite，而弃用Webpack呢？
对于使用 Vite 替换 Webpack ，是由于在实际操作中，确实遇到了一些问题：
Webpack 虽然生态非常完善，但是很多插件都需要自己去手动配置进去；
如果使用的库太多，会导致打包异常变慢。
就拿我之前的Webpack项目来讲！
使用了 croco，启动大概需要5分钟左右。
单纯一个croco配置文件，居然300多行。
在Jenkins 打包大概需要15分钟左右才能完成。
这里主要的问题是开发体验极差！
用windows 电脑几乎无法工作！
最后团队全部切换成Mac M1电脑，打包维持在1分半左右，才得以解决。
所以为了解决这个“包袱”问题，从去年Vite3.0发布之后，我便将新的项目全部切换到Vite 打包。
切换至 Vite 之后，几乎零配置就把一个项目框架搞完了！
启动速度惊掉下巴；
无论是win 还是 mac， dev模式下基本就是200毫秒内。
build 的速度也就1分钟左右！
经过大半年的使用，目前完整项目本地build时间大概在30秒左右，jenkins 打包 2分钟完成。
再也没有人抱怨开发体验差了！
Vite 实际运用的优势有哪些？
还是那句话，简单三个字：快、快、快
1、初始化项目快，一行命令搞定；
2、零配置，上手快；
3、开发启动速度快，编译快；
使用 Vite 快1年了，给人的感觉就是轻松，舒服、快！
如果你是一位前端工程师，还在使用Webpack，那么尽快使用 Vite 吧！
不是因为我有多喜欢它，而是它真的可以给你其他工具给不了的快感！
⛱ 以上就是今天为大家带来的分享！
⛱ 如果文章对你有益；
⛱ 请记得【评论、收藏、转发、点赞】！
⛱ 创作不易，且读且珍惜；
⛱ 喜欢我的文章，记得添加【关注】哦！
⛱ 再次感谢您的阅读。
❀ 长按【点赞】会有惊喜哦！❀
~End~
Vite 入门篇：学会它，一起提升开发幸福感
相信大部分兄弟都体验过 Vite 了，知道它很快。但你知道它为什么快，相比 Webpack 有哪些不同吗？今天咱们就来全面了解一下 Vite ，尤其适合新手兄弟。一起学起来吧！
什么是构建工具
很多人对构建工具没有什么概念，只知道是用来打包的。那么到底什么是构建工具呢？
大家都知道浏览器只支持 Html、CSS、JavaScript，但一个企业级项目可能会用到各种各样的前端技术，如 Less、Sass、TS、Vue组件、语法降级、体积优化等，这时候我们就需要相应的工具去处理这些内容：
使用 less-loader / sass-loader 处理 less / sass
使用 tsc 将 typescript 转换为 javascript
使用 vue-complier 将 vue 组件模板转换为 render 函数
使用 babel 将 es 的新语法转换为旧版浏览器认识的语法
使用 uglifyjs 将我们的代码压缩成体积更小的文件
我们可以手动把代码挨个处理一遍，但这样效率非常低，当我们稍微修改一点代码，这个流程又要重新走一遍，非常麻烦。有个神奇的东西，可以把以上工具集成到一起，整个流程交给它自动处理。而且当代码发生变化时，自动帮我们重新走一遍，这个东西就叫做构建工具。当然构建工具做的事情远不止于此，比如：
模块化开发支持：支持直接从 node_modules 里引入代码
提高项目性能：压缩文件、代码分割
优化开发体验：热更新、跨域问题
……
构建工具减轻了我们的心智负担，让我们不用关心我们写的代码如何在浏览器运行，只需要关心代码怎么写就可以了。市面上主流的构建工具有 Webpack、Vite、esbuild、Rollup、Parcel，以及最近刚出的 turbopack ，但目前最流行的依然是 Webpack 和 Vite 。
Vite 相较于 Webpack 的优势
当项目体积越来越庞大时，构建工具需要处理的代码量呈指数级增长，包含数千个模块的项目也是相当普遍。类似 Webpack 的构建工具就会遇到性能瓶颈：通常需要很长时间，甚至几分钟项目才能启动起来。热更新（HMR）也可能需几秒，甚至十几秒。不知道大家目前的项目怎么样，反正我们公司稍微大一点的 Vue2 项目是真的慢，等的捉急。这种情况已经很大程度影响到了我们的开发效率和幸福感。
Webpack 有没有办法进行优化呢？很难。Webpack 先递归分析各模块依赖关系-构建依赖图谱，然后进行打包，再启动本地服务器。而且 Webpack 支持多种模块化规范，比如 CommonJS 、ES-Module ，一开始就要统一模块化代码，将所有的依赖全部处理一遍。整个流程如下图：
即使使用按需加载，也有一系列工作需要做，所以 Webpack 基本没有优化空间。
那么 Vite 为什么能解决这个问题呢？
底层语言。Vite 使用 esbuild 预构建依赖。esbuild 使用 Go 编写，比用 JS 编写的打包器预构建依赖快 10-100 倍。
先启动服务器，再按需请求模块并编译。Vite 利用的是现代浏览器本身支持 ES-Module 这个特性，直接向依赖的模块发出请求。Vite 启动时不需要分析模块之间的依赖关系，也不用打包，项目越大，优势越明显。
这个是 Vite 的启动过程：
这样大家应该看得出来 Vite 为什么快了吧！
依赖预构建
上面提到了依赖预构建，可能很多兄弟对这个不太理解，这里我也来讲一下。现代浏览器已经支持 ES-Module ，但导入模块只能用相对路径或绝对路径，直接使用模块名称的方式是行不通的：
// main.js
// 假设我们已经安装了 lodash 模块
import a from './a.js' // 支持
import b from '/b.js' // 支持
import _ from 'lodash' // 报错
依赖预构建就可以很好的解决这个问题。Vite 首先会找到依赖的模块，然后调用 esbuild，将 CommonJS 等其他规范的代码转换成 ES-Module 规范，然后把它放在 node_modules/.vite/deps 目录下，接着再修改相应的引入路径。
由于浏览器是通过 HTTP 来请求模块文件的，一旦模块的依赖关系比较多的话，就会发起很多个网络请求。例如，lodash-es 内置模块超过 600 个，它们之前相互导入。当我们执行以下代码时，浏览器会同时发出 600 多个 HTTP 请求！大量的请求造成网络堵塞，导致页面的加载非常的慢。
import { debounce } from 'lodash-es'
这时候还得靠依赖预构建，预构建将 lodash-es 整体转换为一个模块，这样我们就只需要发起一个 HTTP 请求了！
总结一下，依赖预构建为我们解决了以下三个头痛的问题：
兼容其他规范。不同的第三方依赖包会有不同的导出格式（如 CommonJS 规范）。
重写导入路径。例如 lodash 或重写为 /node_modules/.vite/deps/lodash.js?v=fef37e66 ，以便浏览器能够正确导入。
网络性能优化。Vite 会将内部有众多依赖关系的 ES-Module 模块转换为一个模块，提高页面的加载性能。
对不同内容的处理
学习一项技术，最好的方式是单独使用它。抛开脚手架工具，Vite 使用起来也非常的简单，直接在项目中安装 vite ，给个配置就可以了。当然不给也可以，Vite 会使用内置的默认配置：
npm install vite -D
// vite.config.js
import { defineConfig } from 'vite'
export default defineConfig({
// ...
})
为了方便使用，可以在 package.json 添加启动和打包命令。
"scripts": {
"dev": "vite",
"build": "vite build"
}
然后在根目录下新建一个 index.html，npm run dev 项目就跑起来了！
对 CSS 的处理
「CSS Modules」
在不同模块中定义相同类名，会导致样式被覆盖，这时候就要用到 CSS module 。以 .module.css 结尾的文件都会被认为是一个 CSS modules 文件。导入这样的文件会返回一个相应的对象：
/* example.module.css */
.red {
color: red;
}
// main.js
import example from './example.module.css'
console.log(example) // { red: '_red_te83z_1' }
document.getElementById('foo').className = example.red
「CSS 预处理器」
Vite 同时提供了对 .scss，.sass，.less，.styl 和 .stylus 文件的内置支持，仅需安装相应的预处理器就可以了：
# .less
npm install less -D
# .scss and .sass
npm install sass -D
# .styl and .stylus
npm install stylus -D
感觉这块要比 Webpack 简单的多，Webpack 需要给不同类型的文件配置不同的 loader 去处理，而 Vite 内部直接帮我们配置好了。如果使用的是 Vue 单文件组件，可以通过 <style lang=”less”> 自动开启。
「PostCSS」
PostCSS 也是用来处理 CSS 的，只不过它更像是一个工具箱，可以添加各种各样的插件来处理 CSS 。像我们经常遇到的样式兼容性问题，如高级 CSS 语法的降级、前缀补全等，都可以通过 PostCSS 来解决。
Vite 对 PostCSS 有良好的支持，我们只需安装需要使用的插件就可以了。
npm install postcss-preset-env -D
postcss-preset-env 是一个预设环境插件，包含高级 CSS 语法的降级、前缀补全等众多功能。接下来我们在 vite.config.js 中配置一下：
// vite.config.js
import { defineConfig } from 'vite'
import postcssPresetEnv from 'postcss-preset-env'
export default defineConfig({
css: {
postcss: {
plugins: [postcssPresetEnv()]
}
}
})
然后我们来写一些特别的样式：
/* index.css */
.content {
width: clamp(100px, 30%, 200px);
user-select: none;
}
// main.js
import './index.css'
打开浏览器，可以看到 CSS 已经帮我们处理好了：
整体来说 PostCSS 还是非常实用的，可以帮助我们处理各种各样的 CSS 问题。
对静态资源的处理
将资源引入为 URL 。默认情况下引入一个静态资源，会返回这个资源的 URL 路径，也就是绝对路径。
import imgUrl from './img.png'
console.log(imgUrl) // /src/img.png
document.getElementById('hero-img').src = imgUrl
我们可以通过添加后缀的方式，修改文件的引入方式。默认的引入方式等同于添加 ?url 后缀。
import imgUrl from './img.png?url'
将资源引入为字符串。使用 ?raw 后缀可以将资源作为字符串引入，这个字符串其实就是源文件信息。
import imgUrl from './img.png?raw'
console.log(imgUrl) // 源文件信息
document.getElementById('hero-img').src = imgUrl
导入脚本作为 Worker 。JS 脚本可以通过 ?worker 或 ?sharedworker 后缀导入为 web worker。
// worker
import Worker from './shader.js?worker'
const worker = new Worker()
// sharedworker
import SharedWorker from './shader.js?sharedworker'
const sharedWorker = new SharedWorker()
对 JSON 的处理
JSON 文件可以被直接导入。同时也支持具名导入，帮助我们更好地利用 treeshaking ：
// 导入整个对象
import json from './example.json'
// 对一个根属性使用具名导入，有效帮助 treeshaking！
import { field } from './example.json'
对 Vue 的处理
Vite 为 Vue 提供第一优先级支持，直接使用相应的插件就好了：
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
// vite.config.js
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
export default defineConfig({
plugins: [vue()]
})
对 TS 的处理
Vite 天然支持引入 .ts 文件。Vite 使用 esbuild 将 TypeScript 转译到 JavaScript，约是 tsc 速度的 20~30 倍，同时 HMR 热更新也是非常的快 。
Vite 仅执行 .ts 文件的转译工作，并不执行任何类型检查。换句话来说，即使 IDE 提示报错，也不影响正常开发和生成环境打包。这样肯定是不行的，不然很难对代码进行有效约束。我们可以使用插件来实现这个功能：
# 用于检查的插件
npm install vite-plugin-checker -D
# typescript 是 vite-plugin-checker 的依赖
npm install typescript -D
// vite.config.js
import { defineConfig } from 'vite'
import checker from 'vite-plugin-checker'
export default defineConfig({
plugins: [checker({
typescript: true
})]
})
然后在根目录创建 tsconfig.json 文件：
// tsconfig.json
{
"include": ["src/**/*"] // 需要校验的文件夹
}
这样 TS 的报错信息就会在命令行和页面上显示出来，不修正就无法继续往下开发啦！
如果要在类型检查不通过时阻止生产环境打包，直接在 build 命令中添加一个指令即可：
// package.json环境变量与模式
"scripts": {
"dev": "vite",
"build": "tsc --noEmit && vite build"
}
Vite 和 Webpack 类似，都是使用 dotenv 从特定的文件中加载额外的环境变量：
.env # 所有情况下都会加载
.env.development # 开发环境会加载（名称可以通过配置修改）
.env.production # 生产环境会加载（同上）
在客户端中我们使用 import.meta.env 获取环境变量。为了防止意外地将一些环境变量泄漏到客户端，只有以 VITE_ 为前缀的变量才会暴露到客户端，例如使用以下环境变量：
VITE_SOME_KEY=123
DB_PASSWORD=foobar
客户端控制台打印结果：
console.log(import.meta.env.VITE_SOME_KEY) // 123
console.log(import.meta.env.DB_PASSWORD) // undefined
在服务端，也就是 vite.config.js 中，通过 process.env 获取环境变量。但是 vite 考虑到和其他配置的一些冲突问题，Vite 不会将环境变量直接注入到 process.env 对象下。这时候我们可以手动进行处理：
// vite.config.js
import { defineConfig, loadEnv } from 'vite'
export default defineConfig(({ command, mode }) => {
// loadEnv() 第一个参数为当前模式
// 第二个参数为环境变量文件所在目录，process.cwd() 返回当前 node 进程的工作目录
// 第三个参数表示加载以 xxx 开头的环境变量，'' 代表加载所有的环境变量
const env = loadEnv(mode, process.cwd(), '')
console.log(env.VITE_SOME_KEY) // 123
console.log(env.DB_PASSWORD) // foobar
return {
// 配置信息
}
})
实际开发中，我们可能还会用到测试环境和预发布环境，这时候需要创建两个环境变量文件：.env.test 和 .env.staging 。
// .env.test
NODE_ENV=development
VITE_SOME_KEY=456
// .env.staging
NODE_ENV=production
VITE_SOME_KEY=789
然后在 package.json 中添加一下运行指令就可以了。
"scripts": {生产环境构建
"test": "vite --mode test",
"staging": "vite build --mode staging"
}
尽管原生 ES-Module 现在得到了广泛支持，但由于嵌套导入会导致额外的网络往返，在生产环境中发布未打包的 ES-Module 效率仍然非常低（即使使用 HTTP/2）。为了在生产环境中获得最佳的加载性能，更好的利用 tree-shaking、懒加载和 chunk 分割等，Vite 把生产环境构建全权交给了 Rollup 。
我们可以通过 构建配置选项 自定义构建过程，比如，通过 build.rollupOptions 直接调整底层的 Rollup 选项 ，使用 build.assetsInlineLimit 修改图片转 base64 的阈值。
// vite.config.js
export default defineConfig({
build: {
rollupOptions: {
// https://rollupjs.org/guide/en/#big-list-of-options
},
assetsInlineLimit: 4096, // 4kb
}
})
生产环境中，我们不得不考虑一个问题，就是浏览器的兼容性问题。默认情况下，Vite 的目标是支持 原生 ESM script 标签 、支持原生 ESM 动态导入 和 import.meta 的现代浏览器：
Chrome >=87
Firefox >=78
Safari >=13
Edge >=88
但我们可以通过 Vite 自带的 @vitejs/plugin-legacy 插件，来兼容旧版本的浏览器。
# 必须安装 Terser，@vitejs/plugin-legacy 会使用 Terser 进行压缩
npm install terser -D
// vite.config.js
import legacy from '@vitejs/plugin-legacy'
export default {
plugins: [
legacy({
// defaults 是 Browserslist 推荐的值
targets: ['defaults', 'not IE 11']
})
]
}
生产环境还有很多实用的配置，我就不一一介绍了，大家可以在官网查看。
小结
今天的分享内容比较多，不知道大家吸收的怎么样。其实 Vite 还是有很多东西可以讲的，这次主要是帮助大家对 Vite 有一个整体的了解，后面我会继续分享 Vite 配置篇和性能优化篇。有兴趣的兄弟欢迎关注我，关注我的合集 Vue3 特训营 。
如果本文对你有所帮助，记得点赞支持一下哦！
参考资料：Vite 官方中文文档