Como o Bazel continua evoluindo para atender às suas necessidades, queremos compartilhar nossa atualização do planejamento de 2025.
Planejamos oferecer o 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 do Bazel desde o Bazel 7, substituindo o sistema de ESPAÇO DE TRABALHO legado. 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 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, nosso objetivo é implementar um cache de repositório compartilhado aprimorado (consulte #12227) com a coleta de lixo e, talvez, fazer o backport para o Bazel 8. O Registro Central do Bazel 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 a 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, nosso objetivo é desativar o carregamento automático por padrão e exigir que todos os projetos carreguem explicitamente as regras necessárias nos arquivos BUILD.
Vamos reescrever a maior parte do suporte à linguagem C++ para Starlark, desvinculá-lo do binário do Bazel e movê-lo para o repositório /rules_cc. Esse é o último suporte a idioma principal que ainda faz parte do Bazel.
Também estamos transferindo testes de unidade para regras 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 vai 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 após o lançamento do Bazel 9.
Capacidade de configuração
Nosso foco principal é reduzir o custo e a confusão dos 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 em cada lugar. Assim, $ bazel test //foo define automaticamente as
flags corretas com base na política do projeto de foo. Esse recurso provavelmente vai continuar
experimental na versão 9.0, mas feedbacks de orientação são bem-vindos.
O escopo de flag 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 ampliando 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 bordas de dependência precisam propagar flags.
Estamos priorizando o esforço para mover as flags de idioma integradas do Bazel para o Starlark, onde elas podem ser usadas com definições de regras relacionadas.
Melhorias na execução remota
Planejamos adicionar suporte à execução assíncrona, acelerando a execução remota aumentando o paralelismo.
Para acompanhar as atualizações do roteiro e discutir os recursos planejados, participe do servidor Slack da comunidade em slack.bazel.build.
O objetivo deste cronograma é 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.