认识
第一次听到姓名，要在上年（2021）的vueConf，那时我正被webpack漫长装包编译过程摧残到伤脑。PPT里介绍的关于你的每一个特点都像是给我那时候碰到的痛点量身打造的。
换句肉麻的情话，在那一刻，我同你灵魂契合。
“开发工具应用es-module，立即跳过了webpack那繁琐复杂装包阶段”，单这一点就令我茅塞顿开。由于大家在开发工具所使用的浏览器版本广泛比较高，为了能设计阶段的感受，彻底可以省去一部分在工作环境才需要的降权工作中，例如装包。这相当于告知一个已经费劲爬楼得人，不远的地方就会有一部电梯！开发设计用不着与生产在构建战略上有意保持一致，构思与布局从此开启。当然这也引起了不少人顾忌与怀疑，关于这个问题，你作者是那样回复信息:
我就觉得没什么问题，由于我与你的大哥（Vuejs）是很多年的好朋友，所以我会把这份信赖拷贝到你的身上，我敢确信能协调好二者的一致性。
总而言之，我对你第一印象很好，乃至在脑海中早已准备好啦应用你重新构建工程项目的RoadMap。
共处
我的项目是一个应用react ts webpack维修的后台管理系统。架构方面应用vue和你应当是更搭的，终究大家是一家人。但你没有拒绝了，你适用react，这体现了你的格局。
在重新构建过程中遇到的第一个问题，便是绿色生态却不一致，这不是你问题，但确实是我一定要考虑的兼容成本费。我们自己的新项目重度依赖了webpack绿色生态里一个承担条件编译的软件，用以在编译时区别新老2套完全不同管理权限版本号。我在您的绿色生态里找到了相匹配解决方案，可是，他的条件编译词法并不一致，因此，必须更换的代码块或是许多。这不是你的错，因为你文本文档的开篇便说你与webpack大不一样，等同于又吴海英。
后面遇到的困难，全是借鉴一下文本文档就能解决的磕磕绊绊。新项目总算成功奔跑起来了，并且启动项目速度和你服务承诺那般快，本来还担忧初次运行你能预搭建npm依靠，花费的时间会比较长。我现在已经想好怎么安慰自己，但是你并没有给这次机会。我都了解，这也是esbuild功劳。我很激动，内心感慨，我果真并没有弄错你。但随后我发现一件很严重的事儿。
新项目尽管马上就开启了，但当我用浏览器里网页访问详细地址时，长时间一直处于要求“白版”情况。后来我发觉从要求网页页面，到网页页面呈现整整花掉了30s。。。这一度怀疑我的网络或是电脑浏览器出现故障了。
我渐渐去社区论坛上搜索，看是否有和我一样用了vite但换来的是“负优化”（以前webpack地从启动项目到页面展示，一般在15s上下）的事例。我猜测很有可能就是我工程项目的难题，或是配置有不对的地方，终究你npm注册量已经是百万数量级，不会和我玩低级文字类游戏。后来我从在知乎上你创作者那边找到回答：
很悲观，我的项目就是你创作者嘴里的“不想做编码分离的内部结构新项目”。这让我有些惭愧，甚至认为有一些配不上你，但我马上就自我安慰道：这新项目都是接任的女朋友的烫手山芋。此后让我明白了一件事：你并不是一个随便、大大咧咧性情，需要充分发挥你特性，必须顺着你的路线去走。不管怎样，终于找到了缘故，并且相对性也罢改。用React.lazy(()=>import('./pages/xxx.tsx'))将路由器懒加载一下就可以。
此外，我回想起你的特点之一“根据需求编译程序”。我是这样接受的，仅有现阶段用浏览器真正想要访问的控制模块，你才能去编译程序变换。也就是你并不是一个奢侈浪费得人，反而是喜爱勤俭节约勤俭持家，适度原则。这一点非常值得在学习上。
日子完的迅速，我同你中间新鲜感渐渐褪掉。日常生活难免会有小意外、小误会。比如说我有一段时间，常常向周边同事埋怨：你HMR很难使用了，无缘无故更新全部网页页面，不是我接受的热更新，你不过是可有可无的给我点过下浏览器刷新按钮。我耗费数分钟填了一个细细长长表格，认证某一项字段名的功效有没有问题。只因为一不小心保留了一下编码，全部页面情况，我艰辛填报的具体内容都已经被清除了。我渐渐对你有埋怨，我心里想之前应用webpack时，可没有那么多小问题。我后来不经意看到本文才知道，我误会你啊。
换句话说这不是你的错，此次误解是React官方网的锅，主要是因为她们维修的react-refresh在处理函数部件、类部件时的差别所导致的。大致意思是，适用保存状态下的部件级热更新，对函数公式部件更为友善，类部件不兼容。可是我那一个网页页面以前要用类部件达到的。从此次误解以后，我下定了决心把整个项目优化到最少符合的期望的程度。我广泛使用函数式部件重新构建旧网页页面，函数公式部件除开热更新扶持力度高，还有一个好处，便是hook非常容易从部件获取出来，变成复用的自定hook。我因此专业单独了一个npm包来维持这种公共性hook。万万想不到，这件事情引起了我对你的最大的一个误解。
起因是，我还在hook库的开发工具应用rollup的watch模式来即时编译程序元件库，应用npm link package的形式，链接到业务流程新项目里。link是一个很好的，我已浏览到当地hook库的代码，但当我更改了一些hook库的代码后，从你搭建的新项目里，自始至终看不见最新实际效果。我正式开始各种各样清查，查验是否hook库的watch方式没起效，然后重新link，还不行。我渐渐四处寻找回答，最终在文档里，找到有关的描述。造成这些问题的，有两个原因：
1.依靠预搭建
2. 缓存文件。
为了兼容市面上很多非esm单肩包，和避免出现要求飞瀑，这两件事取决于你必须有预搭建这一步，将源代码里提及的npm包提早用esbuild装包好，并把她们缓存文件在node_modules/.vite目录下。
这就意味着调节一个应用npm link连接来的npm包，按基本方法:
- 变更链接库编码
- 删掉新项目
node_modules/.vite文件目录 - npm run dev重新启动自然环境
- 更新电脑浏览器
这就意味着我即便加上一句console,也需要至少之上四个步骤。自然，我明白你有你的现实与苦处，在文档里讲的很搞清楚。
但的确危害到了我的包调节感受。我的建议是能够出一个独立的库开发者模式。在开启此模式后，在刷新页面时，全部依靠禁止使用读缓存文件，反而是即时搭建。这其实慢一点许多，但是我想，远比现在这个样子强。
2022-12-14日升级:
npm run dev加--force能够解决这些问题，详细这儿。哎，也是一场误会。
还有一点，我就是那一天看一个以《跨端》为主题共享突然想起来的。我好像在跨端搭建这种事情上，并不善于。你的一切绝技，不论是 type=“module”的原生载入方法，或是根据浏览器缓存所作的网页页面要求“提升”，都强依赖现代浏览器。例如taro跨微信小程序、uniapp原生态3D渲染这类情景或许直接使用esbuild会更好一些。
所以我认为，“下一代web构建工具”的slogan仿佛比较适合你。
如今
今夜，说了很多我与你的小故事。从一开始对于你的疯狂适用，到今天逐渐回归理性。应用恰当，你仍然对比webpack在构建web页面中快很多，但是你不太适合每一个新项目。比如说你特别适合一些不用非常高的适配规定，但是对可维护性有很高的标准的中后台新项目，由于这类项目通常生命期非常长。但用浏览器以外，例如编译程序跨端运用等场景，或是替代不了webpack。前一阵子，你和turbopack产生了一些争吵，你创作者第一时间出去维护保养你，我表示好羡慕。并且提出大家不是一个方面的物品，乃至未来turbopack的整体来看超出esbuild，可以选择把它内嵌进vite用于预搭建依靠，其实就是变成vite的一部分。不言自明，你一直在设计方案方面一定要“高”一层的，起码在web搭建这一领域都是这样。但我觉得，撇开设计方案上的差别，大家要解决的问题其实就是共通的，都是为提高搭建速率。那就意味着你和他终得巅峰相逢的那一天。待那时候，希望你比更加稳定，更全面。