共计 10240 个字符,预计需要花费 26 分钟才能阅读完成。
咱们晓得,Vite 构建环境分为开发环境和生产环境,不同环境会有不同的构建策略,但不论是哪种环境,Vite 都会首先解析用户配置。那接下来,我就与你剖析配置解析过程中 Vite 到底做了什么?即 Vite 是如何加载配置文件的。
一、流程梳理
咱们先来梳理整体的流程,Vite 中的配置解析由 resolveConfig 函数来实现,你能够对照源码一起学习。
1.1 加载配置文件
进行一些必要的变量申明后,咱们进入到解析配置逻辑中,配置文件的源码如下:
// 这里的 config 是命令行指定的配置,如 vite --configFile=xxx
let {configFile} = config
if (configFile !== false) {
// 默认都会走到上面加载配置文件的逻辑,除非你手动指定 configFile 为 false
const loadResult = await loadConfigFromFile(
configEnv,
configFile,
config.root,
config.logLevel
)
if (loadResult) {
// 解析配置文件的内容后,和命令行配置合并
config = mergeConfig(loadResult.config, config)
configFile = loadResult.path
configFileDependencies = loadResult.dependencies
}
}
第一步是解析配置文件的内容,而后与命令行配置合并。值得注意的是,前面有一个记录 configFileDependencies 的操作。因为配置文件代码可能会有第三方库的依赖,所以当第三方库依赖的代码更改时,Vite 能够通过 HMR 解决逻辑中记录的 configFileDependencies 检测到更改,再重启 DevServer,来保障以后失效的配置永远是最新的。
1.2 解析用户插件
第二个重点环节是 解析用户插件。首先,咱们通过 apply 参数 过滤出须要失效的用户插件。为什么这么做呢?因为有些插件只在开发阶段失效,或者说只在生产环境失效,咱们能够通过 apply: ‘serve’ 或 ‘build’ 来指定它们,同时也能够将 apply 配置为一个函数,来自定义插件失效的条件。解析代码如下:
// resolve plugins
const rawUserPlugins = (config.plugins || []).flat().filter((p) => {if (!p) {return false} else if (!p.apply) {return true} else if (typeof p.apply === 'function') {
// apply 为一个函数的状况
return p.apply({...config, mode}, configEnv)
} else {return p.apply === command}
}) as Plugin[]
// 对用户插件进行排序
const [prePlugins, normalPlugins, postPlugins] =
sortUserPlugins(rawUserPlugins)
接着,Vite 会拿到这些过滤且排序实现的插件,顺次调用插件 config 钩子,进行配置合并。
// run config hooks
const userPlugins = [...prePlugins, ...normalPlugins, ...postPlugins]
for (const p of userPlugins) {if (p.config) {const res = await p.config(config, configEnv)
if (res) {
// mergeConfig 为具体的配置合并函数,大家有趣味能够浏览一下实现
config = mergeConfig(config, res)
}
}
}
而后,解析我的项目的根目录即 root 参数,默认取 process.cwd()的后果。
// resolve root
const resolvedRoot = normalizePath(config.root ? path.resolve(config.root) : process.cwd())
紧接着解决 alias,这里须要加上一些内置的 alias 规定,如 @vite/env、@vite/client 这种间接重定向到 Vite 外部的模块。
// resolve alias with internal client alias
const resolvedAlias = mergeAlias(
clientAlias,
config.resolve?.alias || config.alias || [])
const resolveOptions: ResolvedConfig['resolve'] = {
dedupe: config.dedupe,
...config.resolve,
alias: resolvedAlias
}
1.3 加载环境变量
加载环境变量的实现代码如下:
// load .env files
const envDir = config.envDir
? normalizePath(path.resolve(resolvedRoot, config.envDir))
: resolvedRoot
const userEnv =
inlineConfig.envFile !== false &&
loadEnv(mode, envDir, resolveEnvPrefix(config))
loadEnv 其实就是扫描 process.env 与 .env 文件,解析出 env 对象,值得注意的是,这个对象的属性最终会被挂载到 import.meta.env 这个全局对象上。解析 env 对象的实现思路如下:
- 遍历 process.env 的属性,拿到指定前缀结尾的属性(默认指定为 VITE_),并挂载 env 对象上
- 遍历 .env 文件,解析文件,而后往 env 对象挂载那些以指定前缀结尾的属性。遍历的文件先后顺序如下(上面的 mode 开发阶段为 development,生产环境为 production)
非凡状况下,如果中途遇到 NODE_ENV 属性,则挂到 process.env.VITE_USER_NODE_ENV,Vite 会优先通过这个属性来决定是否走生产环境的构建。
接下来,是对资源公共门路即 base URL 的解决,逻辑集中在 resolveBaseUrl 函数当中:
// 解析 base url
const BASE_URL = resolveBaseUrl(config.base, command === 'build', logger)
// 解析生产环境构建配置
const resolvedBuildOptions = resolveBuildOptions(config.build)
resolveBaseUrl 外面有这些解决规定须要留神:
- 空字符或者 ./ 在开发阶段非凡解决,全副重写为 /
- . 结尾的门路,主动重写为 /
- 以 http(s):// 结尾的门路,在开发环境下重写为对应的 pathname
- 确保门路结尾和结尾都是 /
当然,还有对 cacheDir 的解析,这个门路绝对于在 Vite 预编译时写入依赖产物的门路:
// resolve cache directory
const pkgPath = lookupFile(resolvedRoot, [`package.json`], true /* pathOnly */)
// 默认为 node_module/.vite
const cacheDir = config.cacheDir
? path.resolve(resolvedRoot, config.cacheDir)
: pkgPath && path.join(path.dirname(pkgPath), `node_modules/.vite`)
紧接着解决用户配置的 assetsInclude,将其转换为一个过滤器函数:
const assetsFilter = config.assetsInclude
? createFilter(config.assetsInclude)
: () => false
而后,Vite 前面会将用户传入的 assetsInclude 和内置的规定合并:
assetsInclude(file: string) {return DEFAULT_ASSETS_RE.test(file) || assetsFilter(file)
}
这个配置决定是否让 Vite 将对应的后缀名视为动态资源文件(asset)来解决。
1.4 门路解析器
这里所说的门路解析器,是指调用插件容器进行门路解析的函数,代码构造如下所示:
const createResolver: ResolvedConfig['createResolver'] = (options) => {
let aliasContainer: PluginContainer | undefined
let resolverContainer: PluginContainer | undefined
// 返回的函数能够了解为一个解析器
return async (id, importer, aliasOnly, ssr) => {
let container: PluginContainer
if (aliasOnly) {
container =
aliasContainer ||
// 新建 aliasContainer
} else {
container =
resolverContainer ||
// 新建 resolveContainer
}
return (await container.resolveId(id, importer, undefined, ssr))?.id
}
}
并且,这个解析器将来会在依赖预构建的时候用上,具体用法如下:
const resolve = config.createResolver()
// 调用以拿到 react 门路
rseolve('react', undefined, undefined, false)
这里有 aliasContainer 和 resolverContainer 两个工具对象,它们都含有 resolveId 这个专门解析门路的办法,能够被 Vite 调用来获取解析后果,实质都是 PluginContainer。
接着,会顺便解决一个 public 目录,也就是 Vite 作为动态资源服务的目录:
const {publicDir} = config
const resolvedPublicDir =
publicDir !== false && publicDir !== ''
? path.resolve(
resolvedRoot,
typeof publicDir === 'string' ? publicDir : 'public'
)
: ''
至此,配置曾经基本上解析实现,最初通过 resolved 对象来整顿一下:
const resolved: ResolvedConfig = {
...config,
configFile: configFile ? normalizePath(configFile) : undefined,
configFileDependencies,
inlineConfig,
root: resolvedRoot,
base: BASE_URL
... // 其余配置
}
1.5 生成插件流水线
生成插件流水线的代码如下:
;(resolved.plugins as Plugin[]) = await resolvePlugins(
resolved,
prePlugins,
normalPlugins,
postPlugins
)
// call configResolved hooks
await Promise.all(userPlugins.map((p) => p.configResolved?.(resolved)))
学生成残缺插件列表传给 resolve.plugins,而后调用每个插件的 configResolved 钩子函数。其中 resolvePlugins 外部细节比拟多,插件数量比拟宏大,咱们临时不去深究具体实现,编译流水线这一大节再来具体介绍。
至此,所有外围配置都生成结束。不过,前面 Vite 还会解决一些边界状况,在用户配置不合理的时候,给用户对应的提醒。比方:用户间接应用 alias 时,Vite 会提醒应用 resolve.alias。
最初,resolveConfig 函数会返回 resolved 对象,也就是最初的配置汇合,那么配置解析服务到底也就完结了。
二、加载配置文件详解
首先,咱们来看一下加载配置文件 (loadConfigFromFile) 的实现:
const loadResult = await loadConfigFromFile(/* 省略传参 */)
这里的逻辑略微有点简单,很难梳理分明,所以咱们无妨借助方才梳理的配置解析流程,深刻 loadConfigFromFile 的细节中,钻研下 Vite 对于配置文件加载的实现思路。
接下来,咱们来剖析下须要解决的配置文件类型,依据文件后缀和模块格局能够分为上面这几类:
- TS + ESM 格局
- TS + CommonJS 格局
- JS + ESM 格局
- JS + CommonJS 格局
2.1 辨认配置文件的类别
首先,Vite 会查看我的项目的 package.json 文件,如果有 type: “module” 则打上 isESM 的标识:
try {const pkg = lookupFile(configRoot, ['package.json'])
if (pkg && JSON.parse(pkg).type === 'module') {isMjs = true}
} catch (e) {}
而后,Vite 会寻找配置文件门路,代码简化后如下:
let isTS = false
let isESM = false
let dependencies: string[] = []
// 如果命令行有指定配置文件门路
if (configFile) {resolvedPath = path.resolve(configFile)
// 依据后缀判断是否为 ts 或者 esm,打上 flag
isTS = configFile.endsWith('.ts')
if (configFile.endsWith('.mjs')) {isESM = true}
} else {
// 从我的项目根目录寻找配置文件门路,寻找程序:
// - vite.config.js
// - vite.config.mjs
// - vite.config.ts
// - vite.config.cjs
const jsconfigFile = path.resolve(configRoot, 'vite.config.js')
if (fs.existsSync(jsconfigFile)) {resolvedPath = jsconfigFile}
if (!resolvedPath) {const mjsconfigFile = path.resolve(configRoot, 'vite.config.mjs')
if (fs.existsSync(mjsconfigFile)) {
resolvedPath = mjsconfigFile
isESM = true
}
}
if (!resolvedPath) {const tsconfigFile = path.resolve(configRoot, 'vite.config.ts')
if (fs.existsSync(tsconfigFile)) {
resolvedPath = tsconfigFile
isTS = true
}
}
if (!resolvedPath) {const cjsConfigFile = path.resolve(configRoot, 'vite.config.cjs')
if (fs.existsSync(cjsConfigFile)) {
resolvedPath = cjsConfigFile
isESM = false
}
}
}
在寻找门路的同时,Vite 也会给以后配置文件打上 isESM 和 isTS 的标识,不便后续的解析。
2.2 依据类别解析配置
2.2.1 ESM 格局
对于 ESM 格局配置的解决代码如下:
let userConfig: UserConfigExport | undefined
if (isESM) {const fileUrl = require('url').pathToFileURL(resolvedPath)
// 首先对代码进行打包
const bundled = await bundleConfigFile(resolvedPath, true)
dependencies = bundled.dependencies
// TS + ESM
if (isTS) {fs.writeFileSync(resolvedPath + '.js', bundled.code)
userConfig = (await dynamicImport(`${fileUrl}.js?t=${Date.now()}`))
.default
fs.unlinkSync(resolvedPath + '.js')
debug(`TS + native esm config loaded in ${getTime()}`, fileUrl)
}
// JS + ESM
else {userConfig = (await dynamicImport(`${fileUrl}?t=${Date.now()}`)).default
debug(`native esm config loaded in ${getTime()}`, fileUrl)
}
}
能够看到,首先通过 Esbuild 将配置文件编译打包成 js 代码:
const bundled = await bundleConfigFile(resolvedPath, true)
// 记录依赖
dependencies = bundled.dependencies
对于 TS 配置文件来说,Vite 会将编译后的 js 代码写入临时文件,通过 Node 原生 ESM Import 来读取这个长期的内容,以获取到配置内容,再间接删掉临时文件:
fs.writeFileSync(resolvedPath + '.js', bundled.code)
userConfig = (await dynamicImport(`${fileUrl}.js?t=${Date.now()}`)).default
fs.unlinkSync(resolvedPath + '.js')
以上这种先编译配置文件,再将产物写入长期目录,最初加载长期目录产物的做法,也是 AOT (Ahead Of Time)编译技术的一种具体实现。
而对于 JS 配置文件来说,Vite 会间接通过 Node 原生 ESM Import 来读取,也是应用 dynamicImport 函数的逻辑,dynamicImport 的实现如下:
export const dynamicImport = new Function('file', 'return import(file)')
你可能会问,为什么要用 new Function 包裹?这是为了防止打包工具解决这段代码,比方 Rollup 和 TSC,相似的伎俩还有 eval。你可能还会问,为什么 import 门路后果要加上工夫戳 query?这其实是为了让 dev server 重启后依然读取最新的配置,防止缓存。
2.2.2 CommonJS 格局
对于 CommonJS 格局的配置文件,Vite 集中进行了解析:
// 对于 js/ts 均失效
// 应用 esbuild 将配置文件编译成 commonjs 格局的 bundle 文件
const bundled = await bundleConfigFile(resolvedPath)
dependencies = bundled.dependencies
// 加载编译后的 bundle 代码
userConfig = await loadConfigFromBundledFile(resolvedPath, bundled.code)
bundleConfigFile 函数的次要性能是通过 Esbuild 将配置文件打包,拿到打包后的 bundle 代码以及配置文件的依赖(dependencies)。而接下来的事件就是思考如何加载 bundle 代码了,这也是 loadConfigFromBundledFile 要做的事件。
async function loadConfigFromBundledFile(
fileName: string,
bundledCode: string
): Promise<UserConfig> {const extension = path.extname(fileName)
const defaultLoader = require.extensions[extension]!
require.extensions[extension] = (module: NodeModule, filename: string) => {if (filename === fileName) {;(module as NodeModuleWithCompile)._compile(bundledCode, filename)
} else {defaultLoader(module, filename)
}
}
// 革除 require 缓存
delete require.cache[require.resolve(fileName)]
const raw = require(fileName)
const config = raw.__esModule ? raw.default : raw
require.extensions[extension] = defaultLoader
return config
}
loadConfigFromBundledFile 大体实现的是通过拦挡原生 require.extensions 的加载函数来实现对 bundle 后配置代码的加载,代码如下:
// 默认加载器
const defaultLoader = require.extensions[extension]!
// 拦挡原生 require 对于 `.js` 或者 `.ts` 的加载
require.extensions[extension] = (module: NodeModule, filename: string) => {
// 针对 vite 配置文件的加载非凡解决
if (filename === fileName) {;(module as NodeModuleWithCompile)._compile(bundledCode, filename)
} else {defaultLoader(module, filename)
}
}
而原生 require 对于 js 文件的加载代码如下所示。
Module._extensions['.js'] = function (module, filename) {var content = fs.readFileSync(filename, 'utf8')
module._compile(stripBOM(content), filename)
}
事实上,Node.js 外部也是先读取文件内容,而后编译该模块。当代码中调用 module._compile 相当于手动编译一个模块,该办法在 Node 外部的实现如下:
Module.prototype._compile = function (content, filename) {
var self = this
var args = [self.exports, require, self, filename, dirname]
return compiledWrapper.apply(self.exports, args)
}
在调用完 module._compile 编译完配置代码后,进行一次手动的 require,即可拿到配置对象:
const raw = require(fileName)
const config = raw.__esModule ? raw.default : raw
// 复原原生的加载办法
require.extensions[extension] = defaultLoader
// 返回配置
return config
这种运行时加载 TS 配置的形式,也叫做 JIT(即时编译),这种形式和 AOT 最大的区别在于不会将内存中计算出来的 js 代码写入磁盘再加载,而是通过拦挡 Node.js 原生 require.extension 办法实现即时加载。
至此,配置文件的内容曾经读取实现,等后处理实现再返回即可:
// 解决是函数的状况
const config = await (typeof userConfig === 'function'
? userConfig(configEnv)
: userConfig)
if (!isObject(config)) {throw new Error(`config must export or return an object.`)
}
// 接下来返回最终的配置信息
return {path: normalizePath(resolvedPath),
config,
// esbuild 打包过程中收集的依赖
dependencies
}
三、总结
上面咱们来总结一下 Vite 配置解析的整体流程和加载配置文件的办法:
首先,Vite 配置文件解析的逻辑由 resolveConfig 函数对立实现,其中经验了加载配置文件、解析用户插件、加载环境变量、创立门路解析器工厂和生成插件流水线这几个次要的流程。
其次,在加载配置文件的过程中,Vite 须要解决四种类型的配置文件,其中对于 ESM 和 CommonJS 两种格局的 TS 文件,别离采纳了 AOT 和 JIT 两种编译技术实现了配置加载。