Bazel はお客様のニーズに応えて進化を続けており、このたび 2025 年のロードマップの最新情報をお知らせいたします。
Bazel 9.0 長期サポート（LTS）は、2025 年後半に提供される予定です。
Bzlmod への完全な移行
Bzlmod は、Bazel 7 以降、Bazel の標準の外部依存関係システムであり、以前の WORKSPACE システムに代わるものです。2025 年 3 月の時点で、Bazel Central Registry には 650 を超えるモジュールがホストされています。
Bazel 9 では、WORKSPACE 機能が完全に削除され、Bzlmod が Bazel で外部依存関係を導入する唯一の方法になります。コミュニティの移行費用を最小限に抑えるため、移行ガイドとツールのさらなる改善に注力します。
また、ガベージ コレクションを備えた共有リポジトリ キャッシュの改善（#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 フラグがプロジェクトの境界を越えるときに削除されるため、フラグを必要としない推移的依存関係のキャッシュ保存が中断されることはありません。これにより、トランジションを使用するビルドのコストが削減され、速度が向上します。次に例を示します。このアイデアを拡張して、どのフラグを exec 構成に伝播させるかを制御できるようにします。また、どの依存関係エッジがフラグを伝播させるかを決定するカスタム Starlark などの、より柔軟なサポートも検討しています。
組み込み言語フラグを Bazel から Starlark に移動する作業の優先度を上げています。Starlark では、関連するルール定義とともにフラグを保持できます。
リモート実行の改善
非同期実行のサポートを追加し、並列処理を増やすことでリモート実行を高速化する予定です。
ロードマップの更新をフォローし、計画されている機能について話し合うには、slack.bazel.build のコミュニティ Slack サーバーに参加してください。
このロードマップは、Bazel 9.0 に関するチームの意図をコミュニティに伝えることを目的としています。優先順位は、デベロッパーやお客様からのフィードバック、または新たな市場機会に応じて変更されることがあります。