Bazel はお客様のニーズに応じて進化を続けています。2025 年のロードマップの最新情報をお知らせします。
Bazel 9.0 の長期サポート（LTS）は 2025 年後半に提供される予定です。
Bzlmod への完全な移行
Bzlmod は、Bazel 7 以降、従来の WORKSPACE システムに代わる Bazel の標準外部依存関係システムです。2025 年 3 月現在、Bazel Central Registry には 650 を超えるモジュールがホストされています。
Bazel 9 では、WORKSPACE 機能が完全に削除されます。Bazel で外部依存関係を導入する唯一の方法は Bzlmod になります。コミュニティの移行コストを最小限に抑えるため、移行ガイドとツールのさらなる改善に注力します。
また、ガベージ コレクションを備えた改善された共有リポジトリ キャッシュ（#12227 を参照）を実装し、Bazel 8 にバックポートする予定です。Bazel Central Registry は、SLSA 構成証明の検証もサポートします。
Android、C++、Java、Python、Proto のルールの移行
Bazel 8 では、Android、Java、Python、Proto ルールのサポートを Bazel コードベースから、対応するリポジトリの Starlark ルールに移行しました。移行を容易にするため、Bazel に自動読み込み機能を実装しました。この機能は、--incompatible_autoload_externally フラグと --incompatible_disable_autoloads_in_main_repo フラグで制御できます。
Bazel 9 では、デフォルトで自動読み込みを無効にし、すべてのプロジェクトで BUILD ファイルに必要なルールを明示的に読み込むことを義務付けることを目標としています。
C++ 言語サポートの大部分を Starlark に書き換え、Bazel バイナリから切り離して /rules_cc リポジトリに移動します。これは、Bazel の一部として残っている最後のメジャー言語サポートです。
また、C++、Java、Proto ルールの単体テストを Starlark に移植し、実装の横にあるリポジトリに移動して、ルール作成者の速度を向上させています。
Starlark の改善
Bazel は、シンボリック マクロを遅延評価できるようになります。つまり、宣言されたターゲットがリクエストされていない場合、シンボリック マクロは実行されず、非常に大きなパッケージのパフォーマンスが向上します。
Starlark には、Python の型アノテーションに似た試験運用版の型システムが用意されます。型システムは、Bazel 9 のリリース後に安定すると予想されます。
構成の柔軟性
主な目的は、ビルドフラグのコストと混乱を軽減することです。
Google では、どのビルドフラグとテストフラグをどこに設定すればよいかをユーザーが把握する必要がない新しいプロジェクト構成モデルをテストしています。そのため、$ bazel test //foo は foo のプロジェクトのポリシーに基づいて適切なフラグを自動的に設定します。これは 9.0 でも試験運用版のままになる可能性がありますが、ガイダンスに関するフィードバックをお待ちしています。
フラグのスコープ設定を使用すると、プロジェクトの境界を越えるときに Starlark フラグを削除できるため、フラグを必要としない伝播依存関係のキャッシュが破損することはありません。これにより、遷移を使用するビルドがより低コストで高速になります。例を次に示します。Google は、実行構成に伝播するフラグを制御するアイデアを拡張しており、フラグを伝播する依存関係エッジを決定するカスタム Starlark など、より柔軟なサポートを検討しています。
組み込み言語フラグを Bazel から Starlark に移行し、関連するルール定義とともに存在できるようにする作業に優先度を高めています。
リモート実行の改善
非同期実行のサポートを追加し、並列処理を増やすことでリモート実行を高速化する予定です。
ロードマップの最新情報や予定されている機能について議論するには、コミュニティの Slack サーバーで slack.bazel.build に参加してください。
このロードマップは、Bazel 9.0 に対するチームの意向をコミュニティに伝えることを目的としています。優先順位は、デベロッパーやお客様からのフィードバックや、新しい市場機会に応じて変更される場合があります。