Bazel はお客様のニーズに合わせて進化を続けています。2025 年のロードマップの最新情報をお知らせします。
2025 年後半に Bazel 9.0 の長期サポート （LTS）を提供する予定です。
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 フラグを削除できるため、不要な推移的依存関係のキャッシュが破損することはありません。これにより、移行を使用するビルドのコストと速度が向上します。例 を示します。このアイデアを拡張して、実行 構成 に伝播するフラグを制御します。また、カスタム Starlark などの柔軟なサポートを検討して、 フラグを伝播する依存関係エッジを決定します。
組み込み言語フラグを Bazel から Starlark に移動する作業を優先しています。Starlark では、関連するルール定義とともに使用できます。
リモート実行の改善
非同期実行のサポートを追加し、並列処理を増やすことでリモート実行を高速化する予定です。
ロードマップの最新情報を確認し、計画されている機能について話し合うには、コミュニティ Slack サーバー（slack.bazel.build）に参加してください。
このロードマップは、Bazel 9.0 に対するチームの 意向をコミュニティに伝えることを目的としています。デベロッパーやお客様からのフィードバック、または新しい市場機会に応じて、優先順位が変更される可能性があります。