实际使用中，还有大量的第三方模块不支持esm的规范，看看vite如何解决这个问题。

依赖预构建

首次执行vite时，服务启动后会对node_modules中的模块和 配置了optimizeDeps的目标进行预构建。主要有两个原因

CommonJs和UMD模块的兼容性

开发阶段，vite服务器将所有代码视为原生ES模块，但有很多第三方库还是CommonJs和UMD规范。

提高性能

Vite还会将有许多模块的ESM模块转换为单个模块，以节省http请求。例如lodash-es模块，如果按

import {debounce} from 'lodash-es'

这样导入，浏览器会同时发出600多个http请求来获取其内部独立模块，这无疑是种浪费。

预构建的过程

依赖扫描

项目中存在非常多模块，并不是所有模块都会被预构建。所以第一步vite会做依赖扫描， 目的是找出所有需要预构建的第三方库。简单来说用名称访问的模块会执行依赖预构建，例如

import axios from 'axios' // 名称访问的，会执行预构建
import btn from './btn' // 路径访问的，不会执行预构建

依赖扫描过程依然是从入口文件开始，根据import关系，深度遍历所有模块， 找出所有的import语句，拿到所有需要预构建的依赖信息后，使用esbuild进行打包。

依赖扫描时可以通过设置optimizeDeps选项中的配置来改变扫描依赖项。

export default defineConfig({
  // ...
  optimizeDeps: {
    include: [], // 强制预构建链接的包
    exclude: ['lodash-es'], // 强制排除的依赖项,可测试大量模块的http请求
    force:false // true 强制依赖预构建
  },
})

大致流程

1. 通过依赖扫描收集需要预构建的依赖（也是esbuild的插件）
2. 把依赖信息存储起来，使用esbuild编译
3. 将编译的文件结果存放到node_modules/.vite目录中
4. 下次再使用时直接从.vite目录中获取，而不需要再次编译

依赖缓存

上面说的.vite其实就是预构建的缓存， .vite/deps 目录下_metadata.json的文件存储了所有预构建依赖信息。 下面几个变化会触发重新预构建

1. 包管理器的lockfile改变
2. 补丁文件夹修改
3. vite.config相关配置
4. NODE_ENV改变

当然也可以指定--force 命令行选项启动服务器或者删除.vite目录来强制重新预构建。