vite依赖预构建

vite是一个开箱即用的构建工具,不需要做任何额外的配置就可以使用vite来帮你处理构建工作,在默认情况下我们的esmodule去导入成依赖的时候,要么是绝对路径,要么是相对路径,例如下面这个例子

import { count } from './counter.js'

但是在vite中,支持根据依赖名直接引入,例如:

/* 安装 npm i lodash */
import _ from 'lodash';  // 报错

vite依赖预构建_第1张图片

import _ from 'lodash'; 这种根据依赖名直接引入,js是不支持的,系统提示需要给一个依赖路径。但是我们都知道,安装的依赖会在node_modules中,既然我们现在依赖的最佳实践是node_modules,那么为什么es官方在我们导入非绝对路径和非相对路径的资源时,不默认帮我们搜寻node_modules呢?

举个例子:
我们创建一个counter.js,导出该文件,并在main.js中引入该依赖。

// counter.js
export const count = 100;
// main.js
import { count } from './counter.js'
console.log(count); // 100

vite依赖预构建_第2张图片
main.js是通过http下载下来的,counter.js也是通过http下载下来的,我们引入的依赖,浏览器都会发送http请求,帮我们下载依赖。我们都知道,项目中的依赖基本上都在node_modules中,而node_modules的文件非常多,一些包会将它们的ES模块构建作为许多单独的文件相互导入,下载一个包,浏览器就可能会发送上百个请求。例如:lodash-es,这一个包就有超过600个内置模块。当我们执行 import { debounce } from 'lodash-es' 时,lodash-es可能import了其他东西,文件的互相import会导致浏览器发送成百上千的HTTP请求!尽管服务器在处理这些请求时没有问题,但大量的请求会在浏览器端造成网络拥塞,导致页面的加载速度相当慢。
例如:
vite依赖预构建_第3张图片

为什么common.js可以做呢,因为common.js是运行在服务端的

vite依赖预构建

vite中可以直接通过依赖名称引入依赖,这是因为vite在依赖处理过程中,如果看到了有非绝对路径或者相对路径的引用,它会开启路径补全。例如:

import _ from 'lodash'
// 补全为
import _ from "/node_modules/.vite/lodash"

vite依赖预构建_第4张图片
我们都知道,寻找依赖的过程是自当前目录向上查找,知道搜寻到根目录或者搜寻到对应依赖位置。但如果根目录嵌套了一层目录,vite所谓的路径补全就失效了,因为它从根目录向下寻找的mode_modules并不存在,也就找不到依赖了。

那么vite是怎么解决的呢?

这里需要区分一个问题,生产环境和开发环境
npm run dev : 开发环境(每次依赖预构建重新构建的路径都是正确的)
生产环境 : vite会交给rollup库完成生产环境的打包(这里的路径不一定正确)

依赖预构建:首先vite会找到对应的依赖,然后调用esbuild(对js语法处理的一个库),将其他规范的代码转换成esmodule规范,然后放到当前目录下的node_module/.vite/deps下,同时对esmodule规范的各个模块进行统一集成。
它解决了3个问题:
1、不同的第三方包的导出格式问题
2、对路径的处理直接使用.vite/deps,方便路径重写
3、网络多包的传输性能问题,有了依赖预构建以后,不论有多少个额外的exportimportvite都会尽可能的将他们进行集成,最后只生成一个或几个模块。

// a.js
export default function a(){}
// b.js
// export { default as a } from './a.js 
// vite重写
function a(){
   // 将依赖挂载到函数内再导出
}
export a()

vite依赖预构建官方文档 (点击直达)

你可能感兴趣的:(vite依赖预构建)