単一プロジェクトで複数バージョンのパッケージを使用する: その理由と方法

現代のソフトウェア開発では、特に大規模な JavaScript プロジェクトにおいて、依存関係を管理するための革新的なアプローチが必要になることがよくあります。そのようなアプローチの 1 つは、単一のプロジェクトで同じパッケージの複数のバージョンを使用することです。この方法は、一見型破りに見えますが、レガシー システムのサポートの確保、機能の切り替えの実行、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 

しかし、コンポーネントのバージョンとしてハッシュを持っていても、その目的、親リリースのバージョン、またはコンポーネントの履歴のこの「分岐」に追加の反復があるかどうかについての情報は得られません。

ビット スナップは、git commit のビットの類似点として役立ちますが、運用環境に統合する必要がある実験的なリリース バージョンには役立ちません。

さらに詳しい情報を提供するには、プレリリース オプションを使用することをお勧めします。例:

'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 中国語 Web サイトの他の関連記事を参照してください。