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

目前golang学习网上已经有很多关于文章的文章了，自己在初次阅读这些文章中，也见识到了很多学习思路；那么本文《在单个项目中使用包的多个版本：原因和方式》，也希望能帮助到大家，如果阅读完后真的对你学习文章有帮助，欢迎动动手指，评论留言并分享~

大型 JavaScript 项目的依赖管理常常面临挑战。一种非传统但有效的策略是在单个项目中并行使用同一包的不同版本。这在处理遗留系统、实现特性切换或进行 A/B 测试时尤其有用。本文将深入探讨这种方法的理由，并重点介绍特性切换和 A/B 测试场景，以及 Bit 如何简化此过程。

为何需要同一包的多个版本？

1. 兼容性与逐步升级: 遗留系统通常依赖于特定版本的库。直接升级可能导致不兼容性。使用多个版本允许新功能使用更新的库，同时保持旧系统稳定运行。

2. 特性切换: 特性切换允许在不修改代码库的情况下控制特定功能的启用与禁用。这在增量发布功能或评估其影响时非常有用，包括：

   • 发布切换: 延迟功能的公开发布，同时在主分支中进行测试。
   • 实验切换 (A/B 测试): 允许针对不同用户群体测试功能，以确定最佳实现方案。
   • 运营切换: 赋予运营团队在无需重新部署代码的情况下启用或禁用功能的能力。

当切换涉及重大更改（例如库升级或核心组件修改）时，可能需要使用同一包的不同版本。

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

Bit 提供 bit snap 命令，使用哈希值而非语义版本对组件进行版本控制，指示该版本尚未准备好发布（此命令会执行不同的构建流程）。例如：

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

然而，仅使用哈希值作为版本号并不能提供关于组件用途、父版本或版本历史的信息。bit snap 类似于 Git commit，但并不适用于需要集成到生产环境的实验性版本。

建议使用预发布版本标记，例如：

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

别名方便区分不同版本：

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 <SignInFormWithSso />;
  return <SignInForm />;
}

了解更多

• Bit 文档
• Bit 平台

到这里，我们也就讲完了《在单个项目中使用包的多个版本：原因和方式》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！