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