À medida que o Bazel continua evoluindo em resposta às suas necessidades, queremos compartilhar nossa atualização do planejamento de 2025.
Planejamos oferecer a você o suporte a longo prazo (LTS) do Bazel 9.0 no final de 2025.
Transição completa para Bzlmod
O Bzlmod é o sistema padrão de dependências externas no Bazel desde a versão 7, substituindo o sistema WORKSPACE legado. Em março de 2025, o Registro central do Bazel hospeda mais de 650 módulos.
Com o Bazel 9, vamos remover completamente a funcionalidade 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 nossa 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 para o Bazel 8. O Bazel Central Registry também vai oferecer suporte à verificação de atestados 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 da base de código 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 as flags --incompatible_autoload_externally e --incompatible_disable_autoloads_in_main_repo.
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 da compatibilidade com a linguagem C++ para Starlark, separá-la do binário do Bazel e movê-la para o repositório /rules_cc. Esse é o último suporte a linguagem principal que ainda faz parte do Bazel.
Também estamos portando testes de unidade para regras de C++, Java e Proto para Starlark, movendo-os para repositórios próximos à implementação para aumentar a velocidade dos autores de regras.
Melhorias no Starlark
O Bazel poderá 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 se estabilize depois do lançamento do Bazel 9.
Capacidade de configuração
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 de teste definir e onde. Assim, o $ bazel test //foo define automaticamente as flags corretas com base na política do projeto de foo. É provável que ele continue
experimental no 9.0, mas seu feedback é muito importante.
O escopo de flags permite remover flags do Starlark quando elas saem dos limites do projeto, para que não interrompam 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 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 mover flags de linguagem integradas do Bazel para o 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 roteiro e discutir os recursos planejados, participe do servidor do Slack da comunidade em slack.bazel.build.
Este plano de ação 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.