关于前端: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 依赖预构建官网文档（👈点击中转）