vite的学习之项目的构建

前端小菜菜啊
182 阅读6分钟

前言

首先vite作为下一代的前端构建工具，在越来越广泛的使用，相比与webpack，vite在大型项目的构建速度有不少提升，加上vite的开箱即用的特点,和一些最佳实践的配置让vite越来越受欢迎。本篇文章用作记录个人vite的学习记录，如有错误望请各位大佬指点。

vite开始

什么是构建工具

用大白话来说构建工具就是简化一些繁琐稀碎的操作，让我们码农能将专注力放在业务代码上面，而不用去关心代码是怎么样打包的啊，代码是怎么构建的啊，代码怎么样在本地实现预览等等。说到这可能还不够明白，举一个例子，比如说在使用构建工具的情况下做一个ts+sass+vue3的一个项目，我们npm i安装好了相应的包之后，npm run dev 后就可以再本地开启一个服务器，预览我们的项目了，当项目代码改变后又可以立马在浏览器中看到代码变化。

理解构建工具

假如没有用像vite webpack这类的构建工具你需要怎么办呢，首先还是先下好需要的包，ts，sass,sass-loader,还有转化vue的vue-loader。如果你要执行一个项目要什么步骤呢，首先肯定浏览器是不认识ts的就用tsc将ts转化为js，然后又要用sass-loader将浏览器不认识的sass代码转化为css代码，然后又要执行vue-loader的命令将vue文件解析为js文件，然后你每次修改代码都要按照一定的顺序去执行一窜的命令，才可以将项目启动起来,当项目大起来该怎么办，不可能还是挨个把一大串命令在命令行敲起来吧，如果出错了又该怎么办，不会又要重新把命令全部重新敲一遍吧，是不是太繁琐了，咱们码农明明就头发少，在经过这样折腾岂不是头发都无了，当然这也是个玩笑话，当然也可以看出来构建工具帮了我们多大的忙。

vite的构建

首先大家可能都知道vite的速度很快,这是为什么呢？

4-1.png

这里我们引用官网的这个图相比于webpack的构建图作为比较

4-2.png

可以看到这两个的明显的区别就是本地服务器的启动的时机，vite在一开始就启动本地服务器进行展示，而webpack需要再扫描全部代码后进行服务器的启动，

而为什么webpack需要这样呢，这是因为webpack支持浏览器端和node端的项目的构建，而浏览器端使用的ES的模块化带出导入的规范，而node端的使用的是commentJs的模块化规范，也就是说webpack在代码中要面对两种不同的规范，交给你你会怎么做，当然是统一代码的规范啦所以这就是为什么webpack要扫描全部的代码，就是为了统一规范,至于webpack是如何做到代码的统一的呢？感兴趣的大家可以去这看看Webpack 是如何将不同规范（ESM、CJS、UMD、AMD、CMD）的模块化代码打包到一起并协调它们运行的

vite的依赖预构建

首先我们应该知道在浏览器端原生支持 ES 模块，在浏览器端不使用vite，如果直接写下面的代码会怎么样呢


  import _ from 'lodash';

当然不出意外的话就会给你一个大大错误

4-3.png

这是为什么啊，写这个代码按照我们的理解不是会在nodemodule文件夹里面去找吗，为什么浏览器端叫我们写这种斜杠的写法呢。我们知道比如在lodash里面还引用着其他的依赖，如果我们浏览器找到nodemoule里面的lodash了，lodash又要引入其他的依赖，然后就像一棵树一样引入的东西越来越多，然后浏览器要一直请求资源不断地加载依赖，那浏览器还做不做交互了。

当你再项目使用了vite在写上面这个代码去，发现并不会报错了，这是为什么了

在vite中会将上面的代码补全成了


   import _ from "./nodemodule/.vite/ladash";

4-4.png

那什么使用了vite就可以再nodemodule里面找东西呢，因为vite基于node在本地起了一个开发服务器，在服务器端肯定可以这样搞啊，又不需要网络传输，直接读取文件就可以了

这要归功于vite的依赖预构建

依赖预构建是怎么做的呢？

首先vite会找到对应的依赖，然后利用esbuild(对js语法处理的一个库,详情请见ESbuild的介绍),将其他规范的代码转化为Esmodule的规范,也就相当把代码重新打包了一下，然后vite会将打包好的代码放在当前目录下的node_modules/.vite/deps的目录下，上诉的过程也就是vite的依赖预构建的大概流程

依赖预构建的作用

  1. 解决了不同的第三方包不同的导出格式

  由于第三方的作者的导出格式不一样，但是vite又不能约束，所有在使用esbuild将格式统一转化为Esmodule的规范

  1. 解决了关于路径的问题

   由于vite的依赖寻的过程是由当前目录依次向上的查找的过程，直到搜索到跟目录或者收缩到对应的依赖，当如果搜索到的不是当前的目录肯定要是使用绝对路径，当如在当前目录搜索到了肯定要换为相对路径，当在开发环境上来说是没有问题的，当到了生产环境，通过rollup打包后如果是绝对路径的话，依赖根本会找不到。而依赖预构建的过程将打包好的依赖全部放在了当前目录下的node_modules/.vite/deps的文件夹下，在不论在生产环境还是开发环境都可以使用相对路径队以来进行访问

3.解决了网络多包传输的性能问题


  import _ from 'lodash-es';

这个我们在main.js里面引入lodash-es的库，并且在vite.config.js里配置关闭对于lodash-es的依赖预构建


//vite.config.js

import {defineConfig} from "vite"

module.exports = defineConfig({

    optimizeDeps:{

        exclude:["lodash-es"]

    },

})

我们打开浏览器查看

4-5.png

发现加载了一千多个依赖，这还只是引入了一个包的情况下,如果引入的包越多,那浏览器的性能会大幅度下降，甚至卡死 详情见我的个人博客链接# vite的学习之项目的构建

avatar
文章
阅读
粉丝