相识
第一次听到你的名字，是在上一年（2021）的vueConf，当时我正在被webpack漫长的打包编译进程折磨到抓狂。PPT里介绍的关于你的每一个特性都像是为我当时遇到的痛点量身定制的。
换句肉麻的话，在那一刻，我与你魂灵符合。
“开发环境运用es-module，直接跳过了webpack那繁琐的打包环节”，单这一点就使我醍醐灌顶。因为我们在开发环境运用的浏览器版别普遍较高，为了开发阶段的体会，完全能够省去一部分在生产环境才需求的降级工作，比方打包。这相当于告诉一个正在吃力爬楼梯的人，不远处就有一部电梯！开发没必要与生产在构建战略上故意保持一致，思路与格式就此打开。当然这也引起了不少人的顾虑与质疑，针对这个问题，你的作者是这样回复的:
我也认为问题不大，因为我与你的哥哥（Vuejs）是多年的老友，所以我会将这份信赖仿制到你身上，我相信你能平衡好这两者的一致性。
总之，我对你的第一印象十分好，乃至在脑海里已经计划好了运用你重构项目的RoadMap。
共处
我的项目是一个运用react+ts+webpack保护的后台系统。框架层面运用vue与你应该是更搭的，究竟你们是一家人。但你并没有拒绝我，你支撑react，这体现了你的格式。
在重构进程中遇到的第一个问题，便是生态的不一致，这不是你的问题，但却是我必须考虑的适配成本。我们的项目重度依赖了webpack生态里一个负责条件编译的插件，用于在编译时区分新旧两套天壤之别的权限版别。我在你的生态里也找到了对应的处理方案，可是，他们的条件编译语法并不一致，所以，需求替换的代码块仍是不少。这不是你的错，究竟你文档的开篇就说了你与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原生烘托这种场景或许直接用esbuild会比较好。
所以我觉得，“下一代web构建工具”的slogan如同更合适你。
现在
今晚，讲了许多我与你的故事。从一开端对你的疯狂支撑，到现在逐渐回归理性。运用得当，你依然相比webpack在构建web页面上快很多，但你并不合适一切的项目。比方你十分合适一些不需求很高的兼容要求，但对保护性有较高要求的中后台项目，因为这类的项目往往生命周期比较长。但在浏览器之外，比方编译跨端使用等场景，仍是代替不了webpack。前一阵子，你与turbopack产生了一些争执，你的作者第一时刻出来保护你，我对此表示仰慕。并且指出你们不是一个层面的东西，乃至将来turbopack的整体表现超越esbuild，能够考虑将它内置进vite用来预构建依赖，也便是成为vite的一部分。言下之意，你在规划层面是要“高”一层的，至少在web构建这个领域是这样。可是我觉得，抛开规划上的差异，你们要处理的问题其实是一起的，都是为了提升构建速度。那也就意味着你与他终有高峰相遇的那一天。待那时，我期望你比现在愈加稳定，愈加全面。
