À medida que o Bazel continua evoluindo em resposta às suas necessidades, queremos compartilhar nossa atualização do planejamento de 2025.
Planejamos oferecer suporte a longo prazo (LTS) do Bazel 9.0 no final de 2025.
Transição completa para o Bzlmod
O Bzlmod é o sistema de dependência externa padrão no Bazel desde a versão 7, substituindo o sistema legado do WORKSPACE. Em março de 2025, o Registro central do Bazel hospedava mais de 650 módulos.
Com o Bazel 9, vamos remover completamente a funcionalidade do WORKSPACE, e o Bzlmod será a única maneira de introduzir dependências externas no Bazel. Para minimizar o custo da migração para a comunidade, vamos nos concentrar em melhorar ainda mais nosso guia e ferramenta de migração.
Além disso, pretendemos implementar um cache de repositório compartilhado aprimorado (consulte #12227) com coleta de lixo e talvez fazer o backport dele para o Bazel 8. O Registro central do Bazel também vai oferecer suporte à verificação de atestações da SLSA.
Migração de regras do Android, C++, Java, Python e Proto
Com o Bazel 8, migramos o suporte para regras do Android, Java, Python e Proto do código-fonte do Bazel para regras do Starlark nos repositórios correspondentes. Para facilitar a migração, implementamos os recursos de carregamento automático no Bazel, que podem ser controlados com --incompatible_autoload_externally e --incompatible_disable_autoloads_in_main_repo flags.
Com o Bazel 9, pretendemos desativar os carregamentos automáticos por padrão e exigir que cada projeto carregue explicitamente as regras necessárias nos arquivos BUILD.
Vamos reescrever a maior parte do suporte à linguagem C++ para o Starlark, separá-lo do binário do Bazel e movê-lo para o /rules_cc repositório. Esse é o último suporte de linguagem principal restante que ainda faz parte do Bazel.
Também estamos portando testes de unidade para regras do C++, Java e Proto para o Starlark, movendo-os para repositórios próximos à implementação para aumentar a velocidade dos autores de regras.
Melhorias no Starlark
O Bazel terá a capacidade de avaliar macros simbólicas de forma lenta. Isso significa que uma macro simbólica não será executada se os destinos declarados não forem solicitados, melhorando a performance de pacotes muito grandes.
O Starlark terá um sistema de tipos experimental, semelhante às anotações de tipo do Python. Esperamos que o sistema de tipos seja estabilizado depois do lançamento do Bazel 9.
Configurabilidade
Nosso foco principal é reduzir o custo e a confusão das flags de build.
Estamos testando um
novo modelo de configuração de projeto que não exige que os usuários saibam quais flags de build
e teste definir e onde. Assim, $ bazel test //foo define automaticamente as
flags corretas com base na política do projeto de foo. É provável que isso permaneça experimental na versão 9.0, mas o feedback é bem-vindo.
O escopo de flags permite remover flags do Starlark quando elas saem dos limites do projeto, para que não quebrem o armazenamento em cache em dependências transitivas que não precisam delas. Isso torna os builds que usam transições mais baratos e rápidos. Confira um exemplo. Estamos estendendo a ideia para controlar quais flags são propagadas para as configurações de execução e considerando um suporte ainda mais flexível, como o Starlark personalizado, para determinar quais arestas de dependência devem propagar flags.
Estamos priorizando o esforço para remover as flags de linguagem integradas do Bazel e colocá-las no Starlark, onde elas podem ficar com definições de regras relacionadas.
Melhorias na execução remota
Planejamos adicionar suporte à execução assíncrona, acelerando a execução remota ao aumentar o paralelismo.
Para acompanhar as atualizações do planejamento e discutir os recursos planejados, acesse o servidor Slack da comunidade em slack.bazel.build.
Este planejamento tem como objetivo informar a comunidade sobre as intenções da equipe para o Bazel 9.0. As prioridades estão sujeitas a mudanças em resposta ao feedback de desenvolvedores e clientes ou a novas oportunidades de mercado.