浅析 Vite2.0- 依赖预打包

开始

最近在做业务的时候，理解到了一个叫 imove 开源我的项目，比拟适宜我当初做的业务，便理解了一下，发现它也借鉴了 Vite 的思维：即利用浏览器反对 ESM 模块的特点，让咱们的 import/export 代码间接在浏览器中跑起来。联合之前社区的探讨，同时也让我对 Vite 有了趣味，遂对它的代码进行了一些钻研。
如果你对 Vite 还没有大略的理解，能够先看看这篇中文文档：对于 Vite 的一些介绍。
在我看来比拟重要的点是：

Vite 以 原生 ESM 形式服务源码。这实际上是让浏览器接管了打包程序的局部工作：Vite 只须要在浏览器申请源码时进行转换并按需提供源码。依据情景动静导入的代码，即只在以后屏幕上理论应用时才会被解决
同时我关注 到 Vite 2.0 公布了，其中几个个性还是比拟有意思，接下来就剖析一下 更新的个性之一：基于 esbuild 的依赖预打包。

依赖预打包的起因

对于这一点，Vite 的文档上曾经说得比较清楚了
1.CommonJS 和 UMD 兼容性: 开发阶段中，Vite 的开发服务器将所有代码视为原生 ES 模块。因而，Vite 必须先将作为 CommonJS 或 UMD 公布的依赖项转换为 ESM。
2.Vite 将有许多外部模块的 ESM 依赖关系转换为单个模块，以进步后续页面加载性能。

整体流程

首先 在应用 vite 创立的我的项目中，咱们能够看到有如下几个命令：

  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "serve": "vite preview"
  },

能够得悉，本地运行时启动的就是默认命令 vite。
在 vite 我的项目中找到对应的 cli.ts 代码(为了看起来更清晰，本文档中贴出来的代码相比原文件做了删减)

cli
  .command('[root]') // default command
  .alias('serve')
  .action(async (root: string, options: ServerOptions & GlobalCLIOptions) => {const { createServer} = await import('./server')
    const server = await createServer({root})
    await server.listen()

咱们能够看到 vite 本地运行的时候，简略来说，就是在创立服务。
当然更具体的来讲，createServer 这个办法中做的事包含：初始化配置，HMR(热更新)，预打包 等等，咱们这次重点关注的是预打包。
来看看这一块的代码：

    // overwrite listen to run optimizer before server start
    const listen = httpServer.listen.bind(httpServer)
    httpServer.listen = (async (port: number, ...args: any[]) => {await container.buildStart({}); // REVIEW 简略测试了下 为空函数 貌似没什么卵用？await runOptimize() 
      return listen(port, ...args)
    }) as any
    const runOptimize = async () => {if (config.optimizeCacheDir) server._optimizeDepsMetadata = await optimizeDeps(config);
    }
  }

下面的代码中咱们能够理解到，具体的 预打包代码的实现逻辑就是在 optimizeDeps 这个办法中。同时 config.optimizeCacheDir 默认为 node_modules/.vite，Vite 会将预构建的依赖缓存到这个文件夹下，判断是否须要应用到缓存的条件，咱们前面随着代码深刻讲到。
预构建的流程在我看来，分为三个步骤

第一步 判断缓存是否生效

判断缓存是否生效的重要依据是 通过 getDepHash 这个办法生成的 hash 值，次要就是按程序查找 const lockfileFormats = [‘package-lock.json’,‘yarn.lock’,‘pnpm-lock.yaml’] 这三个文件，若有其中一个存在，则返回其文件内容。再通过 += 局部 config 值，生成文件的 hash 值。
简略来说，就是通过判断我的项目的依赖是否有改变，从而决定了缓存是否无效。
其次还有 browserHash，次要用于优化申请数量，防止太多的申请影响性能。

function getDepHash(root: string, config: ResolvedConfig): string {let content = lookupFile(root, lockfileFormats) || '';
  // also take config into account
  // only a subset of config options that can affect dep optimization
  content += JSON.stringify(
    {
      mode: config.mode,
      root: config.root,
      resolve: config.resolve,
      assetsInclude: config.assetsInclude,
  )
  return createHash('sha256').update(content).digest('hex').substr(0, 8)
}

通过上面的代码能够看到，对依赖的缓存具体门路都写在 optimized 这个字段中，optimized 中的 file,src 别离代表缓存门路和源文件门路，needsInterop 代表是否须要转换为 ESM

  // cacheDir 默认为 node_modules/.vite
  const dataPath = path.join(cacheDir, '_metadata.json') 
  const mainHash = getDepHash(root, config)
// data 即存入 _metadata.json 的文件内容 次要包含上面三个字段
  const data: DepOptimizationMetadata = {
    hash: mainHash,  // mainHash 利用文件签名以及局部 config 属性是否扭转, 判断是否须要从新打包
    browserHash: mainHash, // browserHash 次要用于优化申请数量，防止太多的申请影响性能
    optimized: {}  // 所有依赖项
        //eg: "optimized": {"axios": 
        //{"file": "/Users/guoyunxin/github/my-react-app/node_modules/.vite/axios.js",
      //"src": "/Users/guoyunxin/github/my-react-app/node_modules/axios/index.js",
      //"needsInterop": true }
 }
  // update browser hash
  data.browserHash = createHash('sha256')
    .update(data.hash + JSON.stringify(deps))
    .digest('hex')
    .substr(0, 8)

第二步 收集依赖模块门路

收集依赖模块门路的外围办法是 scanImports 其本质上还是通过 esbuildService.build 办法 以 index.html 文件为入口，构建出一个长期文件夹。在 build.onResolve 的时候拿到其所有的依赖，并在最初构建实现时，删除本次的构建产物。

export async function scanImports(config: ResolvedConfig): Promise<{
  deps: Record<string, string>
  missing: Record<string, string>
}> {entries = await globEntries('**/*.html', config)
  const tempDir = path.join(config.optimizeCacheDir!, 'temp')
  const deps: Record<string, string> = {}
  const missing: Record<string, string> = {}
  const plugin = esbuildScanPlugin(config, container, deps, missing, entries)
  await Promise.all(entries.map((entry) =>
      esbuildService.build({entryPoints: [entry]
        })
    )
  )
  emptyDir(tempDir)
  fs.rmdirSync(tempDir) 
  return {
    deps, // 依赖模块门路
     missing // missing 为 引入但不能胜利解析的模块
  }
}

最终失去的数据结构为

deps =  {
   react:‘/Users/guoyunxin/github/my-react-app/node_modules/react/index.js’,‘react-dom’:‘/Users/guoyunxin/github/my-react-app/node_modules/react-dom/index.js’,
   axios:‘/Users/guoyunxin/github/my-react-app/node_modules/axios/index.js’}

第三步 esbuild 打包模块

最终打包的产物都是会在.vite/_esbuild.json 文件中
以 react-dom 为例 通过 inputs 中的文件打包构建出的产物为 .vite/react-dom.js

   "outputs":{
     "node_modules/.vite/react-dom.js": {
      "imports": [
        {
          "path": "node_modules/.vite/chunk.FM3E67PX.js",
          "kind": "import-statement"
        },
        {
          "path": "node_modules/.vite/chunk.2VCUNPV2.js",
          "kind": "import-statement"
        }
      ],
      "exports": ["default"],
      "entryPoint": "dep:react-dom",
      "inputs": {
        "node_modules/scheduler/cjs/scheduler.development.js": {"bytesInOutput": 22414},
        "node_modules/scheduler/index.js": {"bytesInOutput": 189},
        "node_modules/scheduler/cjs/scheduler-tracing.development.js": {"bytesInOutput": 9238},
        "node_modules/scheduler/tracing.js": {"bytesInOutput": 195},
        "node_modules/react-dom/cjs/react-dom.development.js": {"bytesInOutput": 739631},
        "node_modules/react-dom/index.js": {"bytesInOutput": 205},
        "dep:react-dom": {"bytesInOutput": 45}
      },
      "bytes": 772434
    },

     }

以下为具体打包实现流程

export async function optimizeDeps(
  config: ResolvedConfig,
  force = config.server.force,
  asCommand = false,
  newDeps?: Record<string, string> // missing imports encountered after server has started
): Promise<DepOptimizationMetadata | null> {const esbuildMetaPath = path.join(cacheDir, '_esbuild.json')
  await esbuildService.build({entryPoints: Object.keys(flatIdDeps), // 以收集到的依赖包为入口 即 Object.keys(deps)
    metafile: esbuildMetaPath, // _esbuild.json 中保留着构建的后果 output 
    plugins: [esbuildDepPlugin(flatIdDeps, flatIdToExports, config)]
  })

  const meta = JSON.parse(fs.readFileSync(esbuildMetaPath, 'utf-8'))
  
  for (const id in deps) {const entry = deps[id]
    data.optimized[id] = {file: normalizePath(path.resolve(cacheDir, flattenId(id) + '.js')),
      src: entry,
      needsInterop: needsInterop(id, idToExports[id], meta.outputs)
    }
  }
  writeFile(dataPath, JSON.stringify(data, null, 2)) // 
  return data
}

结尾

本次的文档相交于之前本人钻研的 axios core-js sentry 来说，复杂度会显得稍高一些，而且现有能够查到的对于 vite 的文档根本都是 1.x 版本的，能够借鉴参考的也不多。相比起之前钻研的源码，本次的显得会难一些，所以也是破费了较多的工夫来做，还好最初还是写进去了 233。
之前钻研源码，都是趣味使然，选的方向都比拟随便。最近 1v1 过后，思考了一下技术体系的问题，所以后续应该会是以趣味 + 体系化的形式来抉择要钻研的源码。同时最近 3 个多月，更新了 5 篇技术文档。也缓缓开始有了一些对于写技术文档的一些思考，这也算是一些’副作用’吧。
你如果有什么疑难或者倡议都欢送在下方留言。