Vite
介绍
当我们习惯了在node中编写代码的方式后,在回到前端编写 html、css、js 这些东西会感觉到各种的不便。如:浏览器的兼容性问题,模块过多时的加载问题等。
这个时候就需要一款工具可以对代码进行打包,将多个模块打包成一个文件。这样就解决了上面的问题。
Webpack在诞生之初一直都是主流的存在,它使用ESM规范编写的代码会转换为旧的JS语法,这样可以使得所有的浏览器都可以支持代码。但Webpack也一直有的的痛点就是对于大规模应用的应用启动和热更新的速度很慢且当文件发生变化时,整个JavaScript Bundle文件会被重新构建,对大规模用于的开发者造成了较差的开发体验。
现如今Vite是一种新型的前端构建工具,相较于webpack,它采用了不同的运行方式:
1.开发时,并不会对代码进行打包,而是直接采用ESM的方式来运行项目。
2.在进行项目部署时,在对项目进行打包。
-
因此,针对开发环境中的启动慢问题,Vite开发环境冷启动无需打包,无需分析模块之间的依赖,同时也无需在启动开发服务器前进行编译,启动时还会使用esbuild来进行预构建。而Webpack 启动后会做一堆事情,经历一条很长的编译打包链条,从入口开始需要逐步经历语法解析、依赖收集、代码转译、打包合并、代码优化,最终将高版本的、离散的源码编译打包成低版本、高兼容性的产物代码,这可满满都是 CPU、IO 操作啊,在 Node 运行时下性能必然是有问题。
-
针对HMR慢,即使只有很小的改动,Webpack依然需要构建完整的模块依赖图,并根据依赖图来进行转换。而Vite利用了ESM和浏览器缓存技术,更新速度与项目复杂度无关。可以看到,如Snowpack、Vite这类面相非打包的构建工具,在开发环境启动时只需要启动两个Server,一个用于页面加载,一个用于HMR的Websocket。当浏览器发出原生的ESM请求,Server收到请求只需要编译当前文件后返回给浏览器,不需要管理依赖。
Vite的主要特征
1.lnstant Server Stat ---- 即时服务启动
2.Lightning Fast HMR ---- 闪电般快速的热更新
3.Rich Features ---- 丰富的功能
4.Optimized Build ---- 经过优化的构建
5.Universal Plugin Interface ---- 通用的Plugin接口
6.Fully Typed Apls ---- 类型齐全的API
基本使用
1.安装开发依赖 vite
2.vite 的源码项目就是项目根目录
3.开发命令:
vite 启动开发服务器
vite build 打包代码
vite preview 预览打包后代码
使用命令构建
npm create vite@latest
yarn create vite
pnpm cteat vite
配置文件:vite.config.js
格式:
import { defineConfig } from "vite"
import legacy from "@vitejs/plugin-legacy"
export default defineConfig({
plugins: [
legacy({
targets: ["defaults"]
})
]
})
于主流工具对比
Browserify:
-
预编译模块化方案(文件打包工具);
-
Browserify基于流方式干净灵活;
-
遵循commonJS规范打包JS;
-
可引入插件打包CSS等其他资源(非原生能力)。 Parcel
-
极速打包(工程化:极速0配置)
-
零配置,但造成了配置不灵活,内置常见场景的构建方案及其依赖,无需再次安装(babel等)
-
以html入口,自动检测和打包依赖
-
不支持SourceMap
-
无法Tree-shaking
Webpack
- 预编译模块化方案(工程化:大而全)
- 通过配置文件达到一站式配置
- loader进行资源转换,功能全面(css+js+icon+front)
- 插件丰富,灵活扩展
- 社群庞大
- 大型项目构建慢
Rollup
- 基于ES6打包(模块打包工具)
- Tree-shaking
- 打包文件小且干净,执行效率更高
- 更专注于JS打包
Snowpack
- 基于ESM运行时编译(工程化:ESM运行时)
- 无需递归循环依赖组装依赖树
- 默认输出单独的构建模块(未打包),可选择不同打包器(webpack、rollup等)
Vite
- 基于ESM运行时打包
- 借鉴了Snowpack
- 生产环境使用Rollup,集成度更高,相比Snowpack支持多页面、库模式、动态导入自动polyfill等