在单个项目中使用包的多个版本：原因和方式

现代软件开发经常需要创新的方法来管理依赖关系，尤其是在大型 JavaScript 项目中。其中一种方法是在单个项目中使用同一包的多个版本。这种方法虽然看似非常规，但却可以满足各种需求，例如确保遗留系统支持、进行功能切换或促进 A/B 测试。

在这篇博文中，我们将深入探讨使用多个版本的包背后的原因，重点关注功能切换和 A/B 测试，并探讨 Bit 如何简化这个复杂的过程。

为什么使用同一包的多个版本？

1. 旧代码和逐步更新

遗留系统通常依赖于旧版本的依赖项。引入新版本可能会导致不兼容。使用多个版本可确保新功能可以利用更新的库，同时旧系统保持稳定。

1. 功能切换

功能切换使开发人员能够控制特定功能的可用性，而无需修改代码库。当增量发布功能或测试其影响时，这种方法特别有用。

• 发布切换：延迟功能的公开发布，同时确保其代码在主分支中合并和测试。

• 实验切换：（A/B 测试）：允许测试不同用户群的功能以确定最佳实现。

• 操作切换：为运营团队提供启用或禁用功能而无需部署新代码的能力。

当切换涉及重大更改（例如升级库或更改核心组件）时，功能切换可能需要包或组件的多个版本。

使用预发布版本标记 Bit 组件

Bit 提供了 bit snap 命令来使用哈希而不是语义版本对组件进行版本控制，以指示该版本尚未准备好发布（相应地，该命令还执行略有不同的构建管道）。

例如：

'bit snap' => package-name@5475049d02fafa0eaf6885a06d36e42e0ffdc4a3
'bit tag' => package-name@1.2.3 

但是，将哈希作为组件的版本并不能提供有关其用途、其父版本或组件历史记录的此“分支”是否有其他迭代的任何信息。

bit snap 作为 git commit 的 Bit 类比很有用，但不适用于应该集成到生产中的实验性发行版本。

为了提供更多信息，建议使用预发布选项。例如：

'bit snap' => package-name@5475049d02fafa0eaf6885a06d36e42e0ffdc4a3
'bit tag' => package-name@1.2.3 

管理包的多个版本

当使用包/位组件的多个版本时，依赖别名是关键。这种方法允许团队在同一项目中维护多个包版本。

bit tag forms/sign-in -m "add SSO option" --increment prerelease --prerelease-id beta

别名可以轻松区分版本：

{
 "dependencies": {
  "@my-org/my-scope.forms.sign-in": "0.0.1",
  "@my-org/my-scope.forms.sign-in-sso": "npm:@my-org/my-scope.forms/sign-in@0.0.2-beta.0",
}

了解更多

• 位文档
• 比特平台

以上是在单个项目中使用包的多个版本：原因和方式的详细内容。更多信息请关注PHP中文网其他相关文章！