关于前端:vite-不支持-ie-11configureBuild-Hook-帮你定制-bundle-打包过程

在 5 分钟带你疾速读懂 vite 打包过程，源码剖析一文中，咱们介绍了 vite 打包的代码转化是通过 esbuild 来实现的。而 esbuild 是不反对 ie11 的。所以 vite 的 GitHub 上常常会呈现一些 issue 问如何反对 ie11，例如上面这个 issue：

在这个 issue 下，vite 的几位 contributor 别离讲了几种反对 ie11 的解法：

undefin 大佬：我没有这样测过，仿佛你须要在 rollupOptions 中增加 babel/polyfill 和增加 umd 格局。

在你的 vite.config.js 中增加以下代码，须要留神的是你要装置 core-js、@babel/core、@babel/preset-env、@babel/runtime。

import babel  from '@rollup/plugin-babel';

export default {
  rollupInputOptions: {
    plugins: [
      babel({
        presets: [[
          "@babel/preset-env",
          {
            "corejs": 2,
            "useBuiltIns": "usage",
            "targets": {"ie": "11"}
          }
        ]]
      })
    ],
  }
}

[aleclarson]() 大佬：我做了一个插件 [vite-plugin-legacy]() 用来简略地反对旧的（浏览器）遗留。请期待 #874 合并！

其实相比拟这两位大佬的解法，大体上的思路是一样的，都是围绕 babel 来实现代码的转化、贴片操作。然而，如果较起真来，还是 aleclarson 大佬的 vite-plugin-legacy 比拟贴心。并且，下面提及的 PR 当初曾经合并了，这代表着咱们曾经能够应用 vite-plugin-legacy 插件了！

须要留神的是，vite-plugin-legacy 的次要实现是基于 configureBuild Hook 实现的，而 configureBuild Hook 是在 vite 的 1.0.0-rc.8 版本以及之后才有的。

那么，进入明天的正题，我将带大家一起观赏一番 configureBuild 的外部现象（源码）~

configureBuild Hook 将会在构建性能进行任何操作之前调用。初始化构建配置时，它会被深度拷贝，便于 configureBuild Hook 能够更轻松地对其进行检查和变异（而不须要查看所有未定义的中央）。默认会将 Rollup 的输出（input）选项裸露给 configureBuild，使得 vite 的插件（plugin）能更好地操纵构建过程，并且，意味着更弱小的 vite 插件将成为可能。

vite 打包的大抵过程如下：

通过图例，咱们能够简略理解到 configureBuild Hook 会在打包的最初阶段 生成文件到硬盘 时被调用。

首先，咱们来看一个应用 configureBuild Hook 的插件示例：

定义插件 myPlugin.ts：

export default (): Plugin => ({configureBuild(viteConfig) {
    ...

    return async build => {....}
  }
})

这里，咱们定义了一个箭头函数，它会返回 configureBuild 函数，也就是 configureBuild Hook，它会在打包的开始被调用，并且会传入两个参数 config 和 builds（在前面，我会一一介绍它们）。而 configureBuild 调用会返回一个 async 函数，它会在打包的完结调用。

配置 vite.config.ts：

import myPlugin from "./myPlugin"
import type {UserConfig} from "vite"

const config: UserConfig = {
  plugins: [myPlugin()
  ]
}

export default config

两个步骤，咱们就实现了一个的应用 configuredHook Plugin 的简略示例。尽管，晓得了怎么定义应用 configureBuild Hook 的 Plugin，然而大家可能会对 configureBuild 的参数 build 和 config 是什么、以及如何利用抱有疑难。

那么，接下来，咱们带着这些疑难从源码的角度深刻理解一下 configureBuild Hook~

configureBuild Hook 会在 build 构建办法的开始被调用，首先会创立一个 builds 数组用于保留每个 configuredBuild Hook 操作后果的 bundle，并且 vite 默认打包生成的 bundle 也会放到 builds 中。

// src/node/build/index build()
const builds: Build[] = []

须要留神的是，并不是 configuredBuild Hook 必须要返回 bundle，也能够不返回。

而后，会对用户传入 config 的 options 深度拷贝并填充默认值，这是为了保障后续逻辑的失常进行，而不须要解决不存在某个选项的逻辑，相似于当初 webpack 4 减少了配置默认值一样。

const config = prepareConfig(options)

深度拷贝并填充默认值的实现很简略，首先通过 klona npm 模块来实现对 config 的 options 的深度拷贝，而后通过解构赋值的形式设置默认值。

import klona from "klona/json";

function prepareConfig(config: Partial<BuildConfig>): BuildConfig {
  const {alias = {},
    assetsDir = '_assets',
    assetsInclude = isStaticAsset,
    assetsInlineLimit = 4096,
    ...
  } = klona(config)

  return {
    ...config,
    alias,
    assetsDir,
    assetsInclude,
    assetsInlineLimit,
    base,
    ...
  }
}

接下来，会从 config 中获取到 configureBuild，因为同时可能会存在多个应用了 configureBuild Hook
的 plugin，所以这里取到的 configuredBuild 会是一个数组。而后，再通过 map 办法遍历 configureBuild 数组并调用每一个 configureBuild Hook，将用户的 config、builds 裸露給它。

const postBuildHooks = toArray(config.configureBuild)
    .map((configureBuild) => configureBuild(config, builds))
    .filter(Boolean) as PostBuildHook[]

能够看到，这里 vite 只是将 builds 数组裸露给了 configureBuild Hook，咱们能够选择性地操作 builds。

尽管 configBuild Hook 呈现的目标是为了让用户能更多地操作 bundle 的打包过程，但这并不意味着它的优先级（Priority）是最高的。vite 默认打包生成的 bundle 依然会优先于它被解决，即默认的 bundle 会被搁置到 builds 数组的开始。

const rollup = require('rollup').rollup as typeof Rollup
// 默认打包生成的 bundle
const bundle = rollup({...});

builds.unshift({
  id: "index",
  bundle
});

到这里 builds 数组就构建好了，接下来就是遍历它，进行 bundle 的写操作（即输入到硬盘上），因为 vite 应用的是 Rollup 实现文件的打包，所以这里调用的是 bundle.write 来将文件输入到硬盘上。

for (const build of builds) {
  const bundle = await build.bundle;
  const {output} = await bundle[write ? 'write' : 'generate']({
    dir: resolvedAssetsPath,
    format: 'es',
    sourcemap,
    entryFileNames: `[name].[hash].js`,
    chunkFileNames: `[name].[hash].js`,
    assetFileNames: `[name].[hash].[ext]`,
    ...config.rollupOutputOptions
  });
  build.html = await renderIndex(output);
  build.assets = output
  await postBuildHooks.reduce((queue, hook) => queue.then(() => hook(build as any)),
    Promise.resolve();)
}

默认状况下，write 是为 true，即会调用 bundle.write，将代码写入到硬盘上，这也是为什么咱们的打包后的后果会输入到 dist 目录的起因。在每次遍历 builds 的最初，vite 会调用 postBuildHooks 来应用在开始时调用 configureBuild Hook 返回的函数（通常会是一个 Promise），因为 postBuildHooks 是一个 Promise 数组，所以这里应用了 reduce 办法来保障 Hook 的调用程序。

并且，我想大家应该也留神到，当咱们设置 write 为 false 的时候，此时调用的是 bundle.generate，输入的只是 code 和 sourcemap，如果这样，咱们就须要通过 configureBuild Hook 进行 后续的文件写的操作！而且，咱们还能够在 Hook 中进行一些代码转化操作，例如应用 bable-core 的 transform()，这样一来就很轻松地实现了对 ie11 的反对。

正如 configureBuild Hook 的介绍一样，它的呈现会给 vite 带来更多弱小的插件。例如，咱们能够在 configureBuild Hook 中批改 index.html 中的 <script/>，加载 polyfill.io 提供的垫片文件地址，从而实现对旧浏览器的兼容，这也是 aleclarson 大佬的 vite-plugin-legacy 的实现思路。最初，如果文中存在表白谬误或不当的中央，欢送各位同学提 Issue。

通过浏览，如果你感觉有播种的话，能够爱心三连击！！！

关于前端:vite-不支持-ie-11configureBuild-Hook-帮你定制-bundle-打包过程

前言

configureBuild Hook 介绍

应用 configureBuild Hook 自定义插件

从源码角度意识 configureBuild Hook

写在最初

❤️ 爱心三连击