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

# Web 开发# JavaScript# Node.js

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

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

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

  • 遗留代码和逐步更新

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

  • 功能切换

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

  • 发布切换：延迟功能的公开发布，同时确保其代码在主分支中合并和测试。
  • 实验切换：（A/B 测试）：允许使用不同的用户群测试功能以确定最佳实施方案。
  • Ops Toggles：为运营团队提供无需部署新代码即可启用或禁用功能的能力。

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

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

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

    例如：

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

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

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

    为了提供更多信息，建议使用 `prerelease` 选项。例如：

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

    管理软件包的多个版本

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

    {
 "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",
}

    别名可以轻松区分版本：

    import { SignInForm } from "@my-org/my-scope.forms.sign-in";
import { SignInForm as SignInFormWithSso } from "@my-org/my-scope.forms.sign-in-sso"

export function SignInPage() {
 if (features.flags.sso.enabled) return ;
 return 
  );
}

    了解更多

  • 位文档
  • 比特平台