阅读这篇文章,您可以了解到官网般的详细无漏的却通俗易懂的vite了解
阅读这篇文章,您可以知道什么是vite,为什么选择vite,vite解决了什么问题,vite的浏览器支持
webpack
-
市场份额大
-
生态相对vite更加成熟
-
是思想比较传统和相对没有vite先进的工具
vite
-
是思维比较前卫和先进的工具
-
支持react,vue,angular,svelte
什么是vite
-
vite是一种构建工具
-
由两个主要部分组成
-
一个开发服务器
-
提供比原生es模块丰富的功能逻辑,例如极快的热模块替换(HMR)
-
-
将代码与rollup 捆绑在一起 的 构建命令
-
预先配置为 输出高度优化的 静态资源 以用于生产
-
-
-
vite带有开箱即用的合理默认值
-
vite支持 插件API 和 javascript API 提高扩展性,且提供完整类型支持
为什么选择vite
问题
-
背景
-
在es模块在浏览器可用之前,开发人员 没有以模块化方式编写js 的 原生机制
-
由此,我们有了捆绑的概念
-
使用工具抓取,处理将我们的源模块连接成可以在浏览器中运行的文件
-
-
由此,我们有了捆绑的工具
-
例如webpack,rollup,parcel极大地改善前端开发人员的开发体验
-
-
-
对这应用程序的复杂性越来越大,需要处理的javascript也越来越大
-
捆绑的工具如webpack等开始遇到 性能瓶颈
-
不合理的长时间 等待去启动开发服务器(有时长达几分钟) ,原理见下文
-
缓慢地反馈循环 去将即时更新(HMR:允许模块热替换自身而不影响页面的其余部分)反映在浏览器中中(长达几秒钟),原理见下文
-
-
-
vite如何解决上述问题
-
vite利用生态系统的新进步来解决以上问题
-
浏览器原生ES模块的可用性
-
用 编译为原生语言 编写的 javascript工具 的 兴起
-
Vite vs 捆绑工具 服务器启动缓慢
-
基于捆绑器的构建工具的服务器为什么会启动缓慢
-
冷启动开发服务器时,基于捆绑器的构建必须爬行并构建整个应用程序才能提供服务
-
-
-
vite怎么解决的
-
vite将应用程序的模块分为两类,从而缩短开发服务器的启动时间
-
依赖项
-
特点
-
依赖项大多是纯js,在开发过程中不会经常更改
-
一些大型依赖项的处理成本相当昂贵
-
依赖项拥有各种模块格式,ESM ,CommonJs
-
-
vite的具体解决方案
-
vite使用esbuild(go编写)预捆绑依赖项,预捆绑依赖项的速度比基于javascript的捆绑器快10-100倍
-
-
-
源代码
-
特点
-
源代码通常包含需要转换的非纯javascript(JSX,CSS,Vue,Svelte组件),并且需要经常编辑
-
并非所有的源代码都需要同时加载
-
-
vite的具体解决方案
-
通过ESM提供源代码
-
本质上让浏览器接管了捆绑器的部分工作
-
vite只需要 根据 浏览器的请求 按需转换和提供源代码
-
vite提供基于路由的代码分割
-
-
仅当在当前屏幕上实际使用的时候,才会处理条件 动态导入背后的代码
-
-
-
-
-
Vite vs 捆绑工具更新缓慢
-
为什么基于捆绑器的构建更新缓慢
-
打包文件更改时仍需要重新构建整个捆绑包,更新速度将随着应用程序的大小线性降低
-
后果
-
重建包的成本仍然很高
-
重新加载页面会破坏应用程序的当前状态(可以使用HMR解决:允许模块热替换自身而不影响页面的其余部分)
-
-
-
即使开发服务器在内存中运行捆绑,以便在文件更改时使部分模块图无效
-
vite怎么解决的
-
通过原生执行HMR
-
当文件被编辑时,vite精确地使被编辑的模块与其最近的HMR边界之间的链失效,从而使HMR更新始终快速,而与应用程序大小无关
-
-
利用http标头来提高整页重新加载的速度(让浏览器做更多工作),源代码和依赖模块一旦缓存就不会再次访问服务器
-
源代码模块请求通过304 not modified 进行有条件的处理
-
依赖模块请求通过 cache-control:max-age = 31536000,immutable
-
-
vite捆绑
为什么要在生产环境下做捆绑
-
避免嵌套导入导致额外的网络往返
-
在生产环境中传送非捆绑式 ESM 的效率仍然很低(即使使用 HTTP/2)。
-
-
获得在生产中的最佳的加载性能
-
最好将代码与树摇动、延迟加载和公共块分割(为了更好的缓存)捆绑在一起。
-
-
确保开发服务器和生产构建之间的最佳输出和行为一致性
-
故 Vite 附带一个预配置的构建命令,可以立即进行许多性能优化。
-
为什么不与 esbuild 捆绑在一起
-
esbuild
-
Vite 当前的插件 API 与使用 速度更快的
esbuild
作为捆绑器不兼容
-
-
rollup
-
Rollup 提供了更好的性能与灵活性权衡。
-
灵活的插件API和基础设施做出了巨大贡献
-
致力于性能改进,在 v4 中将其解析器切换为 SWC。
-
正构建一个名为 Rolldown 的 Rollup Rust 端口。
-
一旦 Rolldown 准备就绪,可取代 Vite 中的 Rollup 和 esbuild
-
从而显着提高构建性能并消除开发和构建之间的不一致。
-
Vite 与 X 有何不同?
WMR
-
如何描述
-
就范围而言,它更接近 Preact 元框架,有与 Preact 本身一样强调紧凑的尺寸
-
-
目标受众
-
为Preact项目设计
-
如果您使用 Preact,WMR 可能会提供更精细的体验。
-
-
功能优势
-
提供了更多集成的功能,例如预渲染
-
-
与vite有何关系
-
WMR 提供了类似的功能集,Vite 2.0 对 Rollup 插件接口的支持就是受其启发。
-
@web/dev-server
-
与vite有何关系
-
Vite 1.0 基于 Koa 的服务器设置受到了它的启发。
-
Vite 是一个更加固执己见/更高级别的工具
-
-
如何描述
-
就范围而言有点低级。
-
它不提供官方框架集成 , 且需要为生产构建手动设置 Rollup 配置。
-
-
对vite用户有何帮助
-
@web
伞式项目包含许多其他优秀的工具,也可能使 Vite 用户受益
-
-
Snowpack
-
描述
-
是一个无捆绑的原生 ESM 开发服务器
-
该项目不再维护
-
-
与vite有何关系
-
其范围与 Vite 非常相似
-
除了不同的实现细节之外,这两个项目在技术优势方面比传统工具有很多共同之处
-
Vite 的依赖预捆绑也受到 Snowpack v1(现在的
esinstall
)的启发 -
Snowpack 团队目前正在开发 Astro,这是一个由 Vite 提供支持的静态站点构建器。
-
Astro团队现在是生态系统中的活跃参与者,他们正在帮助改进Vite。
-
-
浏览器支持
开发过程
-
vite转换目标:
esnext
-
假设使用现代浏览器并且它支持所有最新的 JavaScript 和 CSS 功能
-
防止语法降低,让 Vite 提供尽可能接近原始源代码的模块。
-
生产过程
-
Vite 的目标浏览器
-
默认支持原生 ES 模块,原生 ESM 动态导入和
import.meta
-
可以通过官方@vitejs/plugin-legacy 支持旧版浏览器。
-
浏览器兼容性
-
Vite 的目标浏览器支持原生 ES 模块、原生 ESM 动态导入和
import.meta
(生产包假定支持现代 JavaScript):-
Chrome >=87
-
Firefox >=78
-
Safari >=14
-
Edge >=88
-
-
自定义vite的转换目标
-
通过
build.target
配置选项指定自定义目标,其中最低目标是es2015
。
-
-
配置支持旧版浏览器
-
通过@vitejs/plugin-legacy支持旧版浏览器
-
将自动生成 旧版块和相应的ES语言功能polyfill。
-
仅在 不具有本机 ESM 支持的浏览器中 有条件地 加载旧块
-
-
-
注意
-
Vite 默认仅处理语法转换,不涵盖 polyfill。
-
查看 Polyfill.io,一项根据 用户浏览器 UserAgent 字符串 自动生成 polyfill 包 的服务。
-
vite目前的状况
-
已经有大厂在使用vite
-
已经有面试开始拷问vite
-
vite是vue的官方出品
-
vue-cli会将vite作为预设构建工具
-
未来使用vue-cli编写的vue.config.js不再是webpack的配置,而是vite的配置(目前只基于浏览器选项)
-