- 背景：
项目主要用CRA创建，主要用webpack进行编译，编译过程缓慢，因此将此迁移到vite上 ，编译过程结果只需414ms，对比CRA的webpack来说速度快
个人思考：
由于之前对于webpack和vite认知很少
- 经过查阅文档以及跟同事交流，了解到webpack和vite主要区别在于webpack主要是主要是bundle的，比如在jsx，css这种文件需要被转换成js，webpack一开始就将所有的源码进行转化加载。而vite是no bundle的，以esm提供源码，让浏览器去请求源码是转化，import的时候按需动态提供源码。而在依赖层面上官网是这么说的：用esbuild预构建依赖，Esbuild 使用 Go 编写，并且比以 JavaScript 编写的打包器预构建依赖快 10-100 倍。
- 但是基于以上原因，vite编译时虽然快，但切换路由的过程中会比webpack要慢，因为webpack一开始编译的时候编译了所有的源码，但是vite仍然需要找依赖和对应import源码的过程。
- 经与同事交流知，vite和webpack结合使用，在开发下主要用vite，在build的时候用webpack。主要原因如下：开发侧下vite编译过程会比较快，但是vite基于chunk的，假如某一个地方被改变了，未被识别出来，那么build出来的文件会有问题。但是webpack的hash策略，基于所有使用的源文件生成，当文件不改变的时候，使用原来对应的文件，如果hash值发生改变的话，就需要进行重新构建该文件。换而言之，webpack的hash策略以及bundle能够让文件build出来比vite更好。
- 经过思考提出设想：能否利用各自的优点配合使用，在两个配合使用的过程中，先使用vite进行编译，在webpack编译完成的时候，再使用webpack编译好的代码，达到再编译过程和开发使用的过程都比较快的效果。但个人认为如果需要构建该工具需要解决以下问题：
- 如何让webpack的bundle代码与vite正在运行的代码进行无缝切换，切换的话可能会导致重新渲染的问题。
- 能否做到vite已经编译好的代码不动，其余由webpack来进行替换？vite文件会成chunk，webpack则是整体bundle，那么怎么去找到在webpack中哪些是vite已经编译好的文件也是问题所在。 总上所述，完成这样的工具难度大，个人觉得不大可行
