关于前端:vite依赖预构建

vite是一个开箱即用的构建工具，不须要做任何额定的配置就能够应用vite来帮你解决构建工作，在默认状况下咱们的esmodule去导入成依赖的时候，要么是绝对路径，要么是相对路径，例如上面这个例子

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

然而在vite中，反对依据依赖名间接引入，例如：

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

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

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申请！只管服务器在解决这些申请时没有问题，但大量的申请会在浏览器端造成网络拥塞，导致页面的加载速度相当慢。
例如：

为什么common.js能够做呢，因为common.js是运行在服务端的

vite依赖预构建

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

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

咱们都晓得，寻找依赖的过程是自当前目录向上查找，晓得搜查到根目录或者搜查到对应依赖地位。但如果根目录嵌套了一层目录，vite所谓的门路补全就生效了，因为它从根目录向下寻找的mode_modules并不存在，也就找不到依赖了。

那么vite是怎么解决的呢？

这里须要辨别一个问题，生产环境和开发环境
npm run dev : 开发环境（每次依赖预构建从新构建的门路都是正确的）
生产环境 ： vite会交给rollup库实现生产环境的打包（这里的门路不肯定正确）

依赖预构建：首先vite会找到对应的依赖，而后调用esbuild(对js语法解决的一个库），将其余标准的代码转换成esmodule标准，而后放到当前目录下的node_module/.vite/deps下，同时对esmodule标准的各个模块进行对立集成。
它解决了3个问题：
1、不同的第三方包的导出格局问题
2、对门路的解决间接应用.vite/deps，不便门路重写
3、网络多包的传输性能问题，有了依赖预构建当前，不管有多少个额定的export和import，vite都会尽可能的将他们进行集成，最初只生成一个或几个模块。

// a.js
export default function a(){}

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

vite依赖预构建官网文档 （👈点击中转）