在前面两篇文章中，我们介绍了如何对 webpack 进行优化以提升开发体验和构建产物。webpack 无疑是功能强大的构建工具，但是也因为其繁琐的配置项饱受诟病，甚至网友调侃出“webpack配置工程师”这样的岗位。那么本篇文章讲给大家介绍一种新思想：no-bundle 构建方案，也就是无包构建。

# 什么是 no-bundle 构建

在《常见构建工具及对比》中，我们介绍了为什么在现代前端项目需要构建这个环节，并且对比了常见的几种构建工具。在过去的几年中，以 webpack 为主的构建工具无疑占据着主流地位。其核心思想是从一个或多个入口文件开始，根据入口文件递归寻找出依赖文件，然后构建出一个依赖图，最后将你项目中所需的每一个模块组合成一个或多个 bundles，然后在浏览器中加载处理好的 bundles。

webpack 在构建过程中提供了编译、代码效验、文件优化、自动化测试等强大的功能。但也因为如此所以大大增加我们现在 web 开发的复杂性。特别是我们在本地开发的时候，webpack 也会将模块打包为浏览器可读的 js 代码，需要将整个项目都重新构建一遍。项目越大，构建速度就会越慢。

在 bundle 构建时期，主要想解决的问题有以下几点：

模块化的兼容性问题
模块过多导致频繁发送请求影响性能问题

随着技术的发展，上面这些问题或多或少都已经得以解决，比如 HTTP2 的普及大大提高了浏览器对于并发请求的处理；并且现代浏览器普遍都已经支持 ESM 模块。所以前端工程师们又有了新的使命：探索怎么能够简化构建过程提升构建效率。在此背景下，no-bundle 构建方案就孕育而生了。

no-bundle 构建的思想是在构建的时候只处理模块的编译而无需打包，把模块间的依赖关系交给浏览器处理。浏览器加载模块入口之后，进行依赖分析，再通过网络请求加载被依赖的模块。

# JavaScript modules 模块

在《模块化》这部分中，我们带大家一起回顾了 JS 模块化发展的过程。在早期的时候，JS 往往被用来执行独立的脚本任务，简单且体量小。但是随着前端发展，时至今日，我们需要在项目中运行大量的 JS 代码。所以将 JS 拆分为可按需导入的独立模块成为日益明显的需求。

在社区中慢慢出现了一系列的模块化解决方案。CommonJS、AMD、CMD 等。在 ES2015（ES6） 中，官方终于在语言标准层面上实现了模块的功能，并且是浏览器和服务端都支持的模块化解决方案。no-bundle 无包构建的发展就得益于浏览器原生支持模块功能。

由于现代浏览器本身就支持 ES Module，会自动向依赖的Module发出请求。no-bundle 充分利用这一点，简化构建时需要处理的过程，提升构建效率。

# Vite

在了解了什么是 no-bundle 构建之后，我们再来看看具体的应用。

相信一提到 no-bundle 构建工具，大家第一个想到的就应该是 Vite。Vite 是我们熟悉的 Vue 的作者尤雨溪在开发 Vue3.0 的时候开发的一个 基于原生 ES-Module 的前端构建工具。其本人在后来对 Vue3 的宣传中对 Vite 赞不绝口。在 Vite 的官网，我们可以看到对其的介绍是: 下一代前端开发与构建工具。可见对其寄予厚望。

Vite 主要从以下两方面提升开发体验：

在开发时提供开发服务器，基于原生 ESM 提供丰富的内建功能。首次启动以及在模块热更新上速度快到惊人。
针对生产环境使用 Rollup 进行打包代码，输出高可用资源。

也就是在开发环境使用浏览器自带的模块处理能力处理构建过程，只编译不打包，而在生产环境下再使用 Rollup 打包的这种方式，理论上即提高了开发效率，也能够保证生产环境的代码要求。

# Vite 原理

下面我们就带大家来看下 Vite 的原理。

在前面的文章中我们也有讲到，在 bundle 构建时期，例如 webpack 这样的构建工具会从入口文件出发，依次查找文件，生成一个庞大的依赖关系图(dependency graph)，其中包含应用程序需要的每个模块,然后将所有这些模块打包成一个或多个 bundle。

不管是在开发调试还是打包上线的阶段，都会先将你的项目文件打包为一个个的 bundle，进行全量构建。有的同学会说，不是还有懒加载吗？懒加载是发生在项目运行时候的优化手段，在构建的阶段，webpack 还是会将这部分提前构建好的。在项目越来越大的时候，本地开发项目的启动就会越来越慢，达到分钟级别也不足为奇。同时修改代码后的热更新时间也会增加。Vite 为了解决这个问题，使用了浏览器的原生 ESM，并且使用了预编译和 esbuild。

下面我们来具体操作体会下 Vite 的魅力，我们按照姿势一步一步来进行操作，首先我们使用 Vite 来创建一个 Vue 项目（注意 node 版本需要 >= 12.0.0）：

$ npx create-vite-app my-vue-app -- --template vue
npx: 7 安装成功，用时 16.216 秒
Scaffolding project in /Users/workspace/self/my-vue-app...

Done. Now run:

  cd my-vue-app
  npm install (or `yarn`)
  npm run dev (or `yarn dev`)

@前端进阶之旅: 代码已经复制到剪贴板

创建完毕之后，再按照提示依次执行一下命令来打来项目、安装依赖并启动项目：

// 进入到项目目录
cd my-vue-app

// 安装依赖
npm install

// 启动项目
npm run dev

@前端进阶之旅: 代码已经复制到剪贴板

在我们执行完 npm run dev 进行项目启动的时候，就可以明显有秒开的感觉￣ω￣=。大家可以操作体验下~，顺利的话，浏览器会打开 3000 端口并展示如下页面：

在我们开发的时候，Vite 主要做的以下三步内容：拦截请求、替换内容、解析返回结果。 接下来我们就分别来详细看下这部分内容。

# 请求拦截

我们将上一步下载好的 Vue 模板文件中的内容稍微修改下，能够让我们更加直观看到处理过程，我们将 main.js 中的内容直接放在 index.html 中。这时的 index.html 内容如下：

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <link rel="icon" href="/favicon.ico" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Vite App</title>
</head>
<body>
  <div id="app"></div>
  <script type="module" >
    import { createApp } from 'vue'
    import App from './src/App.vue'

    createApp(App).mount('#app')
  </script>
</body>
</html>

@前端进阶之旅: 代码已经复制到剪贴板

再运行项目，我们可以在浏览器中看到，我们源代码的 import { createApp } from'vue'在浏览器中变成了 import { createApp } from '/@modules/vue.js'。

这是因为，在项目启动的时候，Vite 首先会先启动一个 koa 服务器拦截浏览器发出的 ESM 请求，使用 ES Module Lexer 进行处理，Lexer 会找到代码中的 import 语句导入的模块然后以数组的形式返回。然后 Vite 会根据不同的请求类型做不同的处理，最终将处理过的 ESM 的代码返回给客户端。

Vite 在对请求进行处理的时候，会将模块分为依赖和源码两部分分别进行处理，依赖也就是我们存放在 node_modules 下面的三方依赖包，因为我们项目中使用的依赖一般数量会很多，有成百上千个依赖包也不足为奇，并且这些依赖包在开发中大部分情况是不会改变。基于此，Vite 在启动的时候会先使用 esbuild 进行预编译和代码转换（将不是 ESM 的依赖转换为 ESM ），然后将编译结果缓存起来。esbuild 是使用 Go 语言开发的，在速度上会比 webpack 使用的 acorn（JS 开发）要快很多。

# imports 替换

# 依赖 imports 替换

Vite 将所有 import { createApp } from'vue' 这种使用 node_modules下的模块内容写法替换为了 /@modules/xxx，在浏览器中，发出的请求路径就是 /@modules/xxx，然后该请求再次被 Vite 拦截，并经过 vite 的处理之后去寻找正确的模块并返回。

在处理的时候，首先会进行正则匹配，如果是 @modules开头的请求，那么 Vite 就认为是三方依赖。Vite 内部会去 node_modules 中找到正确的依赖模块，将找到的内容经过 esbuild 返回给浏览器。

这样做是因为浏览器并不支持 import { createApp } from'vue' 这样去寻找 node_modules下模块内容的方式，浏览器只能去寻找相对路径或者绝对路径下的内容。我们以前习惯这样写是因为在使用 webpack 的时候，webpack 会帮助我们寻找依赖模块的真正路径，然后经过构建打包之后，返回给浏览器的是正确的路径。

# 静态资源 import 替换

静态资源的处理就相对简单一些，请求路径如果匹配到了图片正则、媒体正则或者字体正则的时候，就会被 Vite 认为是静态资源，相关代码如下：

// https://github.com/vitejs/vite/blob/1.x/src/node/utils/pathUtils.ts
const imageRE = /.(png|jpe?g|gif|svg|ico|webp)(?.*)?$/
const mediaRE = /.(mp4|webm|ogg|mp3|wav|flac|aac)(?.*)?$/
const fontsRE = /.(woff2?|eot|ttf|otf)(?.*)?$/i

/**
 * Check if a file is a static asset that vite can process.
 */
export const isStaticAsset = (file: string) => {
  return imageRE.test(file) || mediaRE.test(file) || fontsRE.test(file)
}

@前端进阶之旅: 代码已经复制到剪贴板

如果是一个静态资源的话，就会被处理成 ESM 返回。

# `*.vue` 文件的替换

下面我们来看一下 Vite 是怎么处理一个典型的 Vue 文件的。我们写一个 App.vue 代码如下：

上面的 App.vue 文件包含了最基础的 template、style 和 script 三部分，Vite 在处理 .vue 后缀的文件时，会将 .vue 文件拆成了 template、css、script 三个模块并行处理。浏览器在请求到 App.vue 文件之后，解析到 template 和 style 的路径，然后再继续对 template、css 发送请求获取其内容。

在 App.vue 中，又将 style 和 template 部分重新组装了起来。

如果 query 的 type 是 template，例如上图的 /src/App.vue?type=template，那么就会使用 compileSFCTemplate 函数将 template 编译为 render function。

# 什么是 no-bundle 构建

# JavaScript modules 模块

# Vite

# Vite 原理

# 请求拦截

# imports 替换

# 依赖 imports 替换

# 静态资源 import 替换

# `*.vue` 文件的替换

# 依赖预构建

# 总结

# 什么是 no-bundle 构建

# JavaScript modules 模块

# Vite

# Vite 原理

# 请求拦截

# imports 替换

# 依赖 imports 替换

# 静态资源 import 替换

# *.vue 文件的替换

# 依赖预构建

# 总结

# `*.vue` 文件的替换

下一代构建方案 no bundle 构建|前端工程化

下一代构建方案 no bundle 构建|前端工程化