Vite 设计与实现

在开发项目时，我发现有时候请求资源的路径是相对路径，有时候是 /@fs/ 开头的绝对路径，这是为什么呢？

Vite 在运行过程中，会记录每个模块间的依赖关系，所有的依赖关系，最终会汇总成一个模块依赖图。利用这个模块依赖图，Vite 能够准确地进行热更新。

我们都知道，Vite 在生产环境中，会使用 Rollup 进行构建，那么 Vite 是如何做到的呢？本文将讲述，从执行 `vite build` 到输出构建产物，这期间到底发生了什么？

Vite 给人一种又快又慢的感觉，快主要体现在 DevServer 的启动和热更新上，但随之带来的问题是，首屏性能不好以及页面加载时间长的问题。那为什么 Vite 的首屏性能不是怎么好呢？

项目升级 Vite3.x 后，首次进入页面，页面的首屏时间非常的长，且一定会刷新整个页面。修复前的页面首屏时间为 1m06s，修复后为 45s，性能提升了 25%

当我们在 Vite 启动后，在编写代码过程中安装了一个新的依赖，并引入到代码中，那这时候 Vite 会怎么处理呢？

当我们使用 Vite 进行开发时，会进行依赖预构建，即将第三方依赖进行打包，并在开发环境下使用这些打包过的第三方依赖。 那这个过程中，Vite 到底做了哪些事情呢？

本文会深入地讲解依赖扫描的实现细节，最终的扫描结果是一个包含多个模块的名字的对象，不涉及预构建的过程、预构建产物如何是使用的。

上篇文章的插件建构架构其实是不够好的，因为可扩展的颗粒度为中间件，中间件内的很多代码都没有复用。 本篇文章，将继续对架构进行改造，实现更细粒度的代码复用

之前手写了一个 Vite Server，实现了一些基本的功能，但是这些能力都是写死的，没有任何的可扩展性，这次我们将它改造成插件化架构，通过新增插件来新增能力。

之前写过几篇 Vite 的文章，对 Vite 的概念也有一定的理解了，但理解归理解，仍然觉得很虚，也不知怎么的，这几个概念突然就变成一个这么强大的工具。。。 于是，我决定自己手写一遍 Vite。

我们知道，Vite 在开发环境下，会打开一个 Dev Server 用于预览开发的页面，那么这个 Dev Server 到底做了什么呢？它是怎么做到将我们的代码展示成页面的，接下来我们就来一探究竟。

我们知道，Vite 开发时，用的是 esbuild 进行构建，而在生产环境，则是使用 Rollup 进行打包。 Vite 官方文档已经做出解析：尽管原生 ESM 现在得到了广泛支持，但由于嵌套导入会导

准备 拉取源码，安装依赖，并进行一次构建 调试内置项目 vite 的内置项目，在 playground 文件夹内，里面有非常多项目，我们挑选其中的 vue 项目进行测试 watch 模式打包 vite

这篇文章，主要是分析一下，vite 是如何解析它的配置的，我们定义的 vite.config.ts 配置文件，最终会被转换成什么样子，被 vite 的整个执行过程中使用。

本文讲的会讲述热更新的每个流程，主要的作用是什么，还有这些流程是怎么串起来的，目的是帮助大家对热更新的流程有个基本的了解。

最近在做 monorepo 的 npm 包发布，参考（照抄）了 Vite 的发布方式。然而当我写完的第二天，Vite 重构了它的发布脚本（2022/2/11）😭😭😭 于是，我又再次的修改了项目