Bun.lockb 文件应该进行版本控制吗？

Question

我正在迁移 Laravel+Sail 项目以使用bun而不是nodejs。

根据Bun 文档，运行后，会创建一个名为（类似于）bun i的二进制锁定文件以提高性能。我应该将此文件添加到我的文件中吗？bun.lockbyarn.lock.gitignore

Answer 1

如果您想要可重复的构建（您可能会为任何大型项目执行此操作），那么它应该如此。对于小型实验，你并不真正需要它。您链接到的 Bun 文档还包含解释如何配置本地 git 以正确显示其差异的步骤。

至于对二进制文件进行版本控制是否是一个好主意是另一个话题。差异不会显示在 GitHub 上，并且对经常更改的二进制文件进行版本控制可能会导致存储库大小大幅增加，具体取决于文件更改的稳定性以及压缩的效率 - 这是一个未提及的主题全部在bun文档中。

为了保持安全，直到你确定bun.lockd不会让你的存储库膨胀，你可以选择退出bun二进制锁并使用yarn文本锁，但我还没有尝试过。

编辑：我在一个安装了大约 900 个软件包的项目（基本上是一个现代的 javascript hello world）上使用 Bun Lockfile 与 pnpm Lockfile 进行了快速测试。这些是它生成的尺寸。

100866 bun-both.7z
100620 bun-old.7z
 84577 pnpm-both.7z
 82288 pnpm-old.7z

-old文件是初始压缩锁定文件。-both文件包含初始锁 + 当我更新项目（Vite）中的一个大依赖项时生成的新锁。最初的包二进制文件较大，但压缩后，整体大小的增加较小。所以看来事情并没有我最初想象的那么糟糕

Answer 2

的版本控制bun.lockb如果您需要确保安装时的可重现依赖性，则

\n

重用 @Joachim Bauer 的示例，想象一下有一个像 foo = \xcb\x863.0.0 （最新的次要版本）这样的依赖项和一个每次都会安装和构建它的 CICD 管道。如果 foo 存储库突然升级，它将安装该依赖项的新版本，可能会导致一些新错误，因为您在开发时引用了旧版本。

\n

但也许您不想避免使用该\xcb\x86字符，因此您不必手动检查更新。\nBun 具有命令选项，--frozen-lockfile因此install它将检索文件上的确切版本bun.lockb，以确保您在开发它时所使用的依赖项。

\n