Última verificação: 21/04/2020 (histórico de atualizações)
Ponto de contato: laurentlb
Meta
Nosso objetivo é tornar o Bazel mais extensível. Os usuários devem poder implementar próprias regras facilmente e oferecer suporte a novas linguagens e ferramentas. Queremos melhorar a experiência de escrever e manter essas regras.
Nós nos concentramos em duas áreas:
- A linguagem e a API precisam ser simples, mas eficientes.
- Fornecer ferramentas melhores para ler, gravar, atualizar, depurar e testar o código.
2º trimestre de 2020
Integridade e práticas recomendadas de criação:
- P0. Identifique as macros sem ter um nome e verifique se o nome é um literal de string exclusivo. Este trabalho é focado na base de código do Google, mas pode afetar as ferramentas disponíveis publicamente.
- P0. Torne os comandos do Buildozer confiáveis no que diz respeito a seleções e variáveis.
- P1. Faça o Buildifier remover cópias em listas que não classificamos por comentários.
- P1. Atualização do linter do Buildifier para recomendar expressões triviais in-line
- P2. Estude os casos de uso de native.existing_rules e proponha alternativas.
- P2. Estude casos de uso para o arquivo de prelúdio e proponha alternativas.
Performance:
- P1. Otimizar o interpretador do Starlark usando ambientes simples e compilação de bytecode.
Redução de dívida técnica:
- P0. Adição do recurso de portabilidade de símbolos nativos para o Starlark abaixo de @bazel_tools.
- P1. Exclua as sinalizações obsoletas (algumas ainda são usadas no Google, então precisamos
limpar a base de código primeiro):
incompatible_always_check_depset_elements,incompatible_disable_deprecated_attr_params,incompatible_no_support_tools_in_action_inputs,incompatible_new_actions_api. - P1. Verifique se as sinalizações a seguir podem ser invertidas no Bazel 4.0:
incompatible_disable_depset_items,incompatible_no_implicit_file_export,incompatible_run_shell_command_string,incompatible_restrict_string_escapes. - P1. Concluir o trabalho lib.Sintaxe (limpeza da API, separação do Bazel).
- P2. Reduza em 50% a latência de compilação e teste de uma edição trivial para os pacotes Java do Bazel.
Comunidade:
- O
rules_pythonestá ativo e é bem mantido pela comunidade. - Suporte contínuo para Rules_jvm_external (sem solicitações de envio pendentes, triagem de problemas, realização de versões).
- Mantenha a infraestrutura de documentação do Bazel: centralize e canonize os estilos CSS em bazel-website, bazel-blog, docs.
- Documentos do Bazel: adicione testes de CI para criação de sites de documento e2e para evitar regressões.
1º trimestre de 2020
Integridade e práticas recomendadas de criação:
- Permitir que os destinos acompanhem a pilha de chamadas macro para exportação via
bazel query - Implemente o
--incompatible_no_implicit_file_export. - Remoção das APIs depset descontinuadas (#5817, #10313, #9017).
- Adicione um analisador de arquivo cruzado no Buildifier e implemente uma verificação para funções descontinuadas.
Performance:
- Torne os testes baseados no Java do Bazel duas vezes mais rápidos.
- Implementar um criador de perfil de CPU do Starlark.
Redução de dívida técnica:
- Remova oito sinalizações incompatíveis (depois de invertê-las).
- Concluir o trabalho de limpeza de lib.Sintaxe (interromper dependências).
- Otimização do Starlark: ambiente simples e compilação de bytecode
- Exclua toda a serialização da fase de análise, se possível
- Criar um plano para simplificar/otimizar pacotes.
Comunidade:
- Publicar um glossário com definições para todos os termos específicos do Bazel