bun（仍然无法替换节点（但这是我一起使用它们的方式）

来到golang学习网的大家，相信都是编程学习爱好者，希望在这里学习文章相关编程知识。下面本篇文章就来带大家聊聊《bun（仍然无法替换节点（但这是我一起使用它们的方式）》，介绍一下，希望对大家的知识积累有所帮助，助力实战开发！

Bun的基准测试结果令人印象深刻，其HTTP服务器性能在框架性能榜单中名列前茅，这让我眼前一亮。npm包的安装速度也显著提升，甚至让我考虑放弃pnpm。

然而，在实际使用过程中，我发现了一些问题。 最初，我对Bun宣传中的一些说法持怀疑态度，但现在我更倾向于认同其部分观点。

我遇到的主要问题在于对运行时无关的包（例如Amazon S3和SQLite库）的支持不足。我认为Bun在开发者体验方面还有提升空间。 我使用Bun和VS Code的过程中，调试功能存在诸多问题：

• Bun不总是能正确识别断点，除非运行时存在端口监听器或某些函数处于“挂起”状态。inspect-brk 和 inspect-wait 也无效，即使使用了官方的Bun VS Code扩展和Volta.sh。
• 调试器的行为在启动和“运行文件”之间不稳定，尤其是在远程/隧道和本地开发环境之间切换时。
• 网络调试器也存在问题，尤其是在处理await时，它可能会完全丢失某些等待中的Promise。
• 即使使用source map，JavaScript代码也无法正确映射到同一monorepo中的TypeScript文件。 我不得不手动杀死端口才能解决端口被占用问题，为此我创建了以下tasks.json文件：

Bun的测试运行器虽然功能强大，但与VS Code的测试资源管理器集成度不高，导致难以可视化和运行在VS Code中最后一次运行中失败的测试。虽然它具有CLI中的过滤器选项，但需要手动指定失败的测试，调试体验也不佳。此外，我还遇到了一些奇怪的断言错误，这可能与Bun处理monorepo的方式有关。  我不得不使用obj.constructor.toString() === className.toString()来替代instanceof操作来解决这个问题。

Bun在处理monorepo和多根工作区时也存在不足。构建和安装过程有时会与存储库中的包冲突，这在使用npm时从未遇到过。VS Code也不总是能正确识别Bun的启动配置。
Bun的构建过程虽然很快，但它接受了一些TypeScript编译器（tsc）不允许的代码，并且对tsconfig.json的遵守也不够严格。默认情况下，Bun会将所有外部模块打包到捆绑包中，外部和包标志的使用也比较混乱。
最终，我为项目中Bun的使用制定了以下策略：
库: 使用tsc进行编译，以提高速度并确保与CommonJS兼容。
调试: 使用Node.js和source map进行调试，以便在VS Code中正确调试TypeScript代码。
服务器/应用程序: 使用Bun，因为它在运行时更快、更高效。
包管理器和脚本: 使用Bun（虽然pnpm也是一个不错的选择，尤其是在减少磁盘空间占用方面）。
总而言之，Bun是一个很有潜力的工具，但它在开发者体验方面仍有改进空间，尤其是在调试、monorepo和多根工作区支持方面。  在选择使用Bun时，需要仔细权衡其优势和不足。
今天关于《bun（仍然无法替换节点（但这是我一起使用它们的方式）》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！