Alterar uma biblioteca de componentes de interface e verificar que nada quebrou

## Rodar os comandos a partir da raiz com o gerenciador de pacotes do repositório Use somente o gerenciador de pacotes e o estilo de comandos do espaço de trabalho declarados pelo repositório. Execute operações limitadas a um pacote por meio do filtro de espaço de trabalho do gerenciador a partir da raiz, em vez de entrar nos diretórios de pacotes e invocar outra ferramenta. Instale dependências somente quando necessário. Durante a iteração, prefira o comando de compilação, teste, análise estática ou verificação de tipos com o menor escopo de pacote possível e reserve compilações de todo o repositório para verificação de integração ou lançamento. Mantenha como fluxos de trabalho distintos o desenvolvimento da documentação, as compilações de pacotes, as compilações da documentação, os testes unitários, os testes de navegador, os testes de ponta a ponta, os testes de regressão visual, a formatação, a análise estática e a verificação de tipos. ## Colocar componentes novos na área experimental e não expor os pacotes internos Divida a biblioteca em componentes principais, sistema de estilos, componentes experimentais, ícones ou recursos, utilitários compartilhados, abstração do mecanismo de estilos e pacotes internos não publicados. Respeite quais pacotes são públicos e quais existem apenas para dar suporte ao espaço de trabalho. Introduza componentes novos ou instáveis na área experimental designada antes de promovê-los ao pacote estável. Mantenha os estilos compartilhados e o comportamento de temas na camada de estilos, em vez de duplicá-los entre componentes. Não exponha pacotes internos por pontos de entrada públicos nem contorne a abstração configurada do mecanismo de estilos com suposições específicas da implementação. ## Organizar os arquivos de cada componente e importar só o necessário Siga o arranjo de arquivos de componentes do repositório para implementação, declarações, testes, classes de estilo e exportações públicas. Mantenha cada responsabilidade no arquivo que a possui para que a documentação da API, os testes e a eliminação de código não utilizado continuem previsíveis. Use a forma de declaração exigida pelo repositório para propriedades públicas dos componentes e exporte do módulo do componente uma interface de propriedades com nome consistente. Preserve os aliases de caminho e as convenções de exportação pública. Use importações de pacotes específicas e de um único nível dentro do espaço de trabalho quando importações amplas de arquivos agregadores incluírem um pacote inteiro no pacote gerado. Trate a forma da importação como um contrato de desempenho e empacotamento, não como preferência de estilo. ## Escrever erros que digam o que aconteceu e como corrigir Todo erro lançado por um pacote público deve informar o que aconteceu, por que isso importa e o que o chamador pode fazer para corrigir. Use o prefixo obrigatório da biblioteca, uma construção legível da mensagem e um link para a documentação quando houver orientação mantida. Aplique o marcador de minificação de erros do repositório aos construtores de erro compatíveis, para que os pacotes de produção possam substituir mensagens longas por códigos estáveis, enquanto o desenvolvimento continua compreensível. Depois de adicionar ou alterar um erro público, gere novamente o catálogo de códigos de erro. Se a semântica e a quantidade de argumentos não mudarem, atualize a entrada existente do catálogo em vez de criar um novo código para o mesmo contrato de erro. ## Testar os componentes como um usuário que clica e digita Use o renderizador e os utilitários de asserção compartilhados do repositório para que os testes de componentes correspondam ao ambiente compatível. Prefira consultas acessíveis e interações completas do usuário ao disparo de eventos de baixo nível ou à modificação direta de propriedades. Teste o comportamento observável, as transições de estado, os avisos e os erros com os comparadores configurados. Mantenha os testes unitários focados e use filtros de nome durante a iteração, sem confundir a aprovação de uma execução filtrada com cobertura completa. Quando um teste exigir leiaute, API do navegador ou comportamento de renderização indisponível em um DOM simulado, restrinja-o ao ambiente compatível de navegador real e documente o motivo na condição do teste. ## Desligar as capturas de tela sem desligar as verificações de acessibilidade Execute a análise de acessibilidade dentro do ciclo estabelecido de regressão do navegador quando o repositório compartilhar essa sessão. Trate capturas de tela e asserções de acessibilidade como controles independentes: uma demonstração pode desativar um deles sem desativar implicitamente o outro. Mantenha explícita a cobertura das regras de acessibilidade. Registre resultados aprovados, reprovados e incompletos por demonstração e regra, inclua as etiquetas aplicáveis do padrão de acessibilidade e preserve as asserções obrigatórias, exceto quando houver uma exceção de escopo restrito e devidamente justificada. Não inicie um fluxo de trabalho de navegador separado quando a estrutura integrada de regressão já for responsável por navegação, renderização, capturas de tela e análise de acessibilidade. ## Ordenar as regras de exceção para que pular uma demonstração não pule outras Compare a configuração de regressão com identificadores estáveis de demonstração. Quando as regras usarem precedência da última correspondência sem herança, coloque substituições de escopo restrito depois das regras amplas e declare novamente todos os campos que a substituição pretende manter. Use padrões restritos para demonstrações individuais e padrões mais amplos apenas para um grupo completo de componentes. Uma regra que desative uma única demonstração não pode desativar por engano as demais nem herdar campos de exceção desatualizados. Gere novamente os resultados estruturados de acessibilidade e visuais depois de alterar as regras. A integração contínua deve rejeitar relatórios gerados desatualizados, em vez de aceitar silenciosamente uma configuração que nunca foi exercitada. ## Testar só o que foi afetado durante o trabalho e rodar todos os testes antes de enviar Limite as execuções locais de regressão com o filtro de nome do executor de testes, para que testes sem correspondência não acionem a navegação do navegador nem reescrevam resultados não relacionados. Confirme que o filtro corresponde à rota ou ao identificador de demonstração incorporado ao nome do teste. Entenda que uma execução filtrada atualiza apenas os relatórios de componentes correspondentes. Antes de enviar as mudanças, execute o comando de regressão sem filtro para que todos os relatórios, capturas de tela e resultados de acessibilidade estejam atualizados. Mantenha o servidor de regressão e o executor como processos separados quando o fluxo de trabalho do repositório exigir e preserve a sintaxe documentada do gerenciador de pacotes para encaminhamento de argumentos. ## Gerar de novo a documentação da API e as demonstrações após alterar um componente Depois de alterar propriedades de componentes ou declarações de tipos, execute os geradores de extração de propriedades e de documentação da API. Analise a diferença resultante da API pública junto com a alteração no código-fonte. Crie a demonstração tipada designada como fonte oficial e gere variantes em outras linguagens por meio do formatador ou conversor suportado. Não edite manualmente uma variante de demonstração gerada como única correção. Quando demonstrações ou Markdown mudarem, execute as verificações correspondentes de geração de demonstrações, compilação da documentação, estilo de texto e gramática. Mantenha orientações especializadas de integração em módulos locais de instruções autônomos e carregue o módulo relevante para trabalhos de estilos, temas, renderização ou integração com arcabouços. ## Fazer as verificações que a alteração pede e avisar quais ficaram de fora Antes da revisão, formate os arquivos alterados, execute a análise estática e a verificação de tipos, realize testes unitários específicos e amplie para verificações em navegador real, de ponta a ponta, visuais, de acessibilidade, de documentação da API ou de texto, conforme o comportamento afetado. Verifique códigos de erro gerados, referências da API, variantes de demonstração, capturas de tela e relatórios de acessibilidade quando suas fontes mudarem. Relate qualquer controle bloqueado ou não executado, em vez de apresentar verificação parcial como completa. Mantenha a revisão focada no componente e use o formato de título de mudança exigido pelo repositório: um escopo estável de componente ou documentação seguido de uma descrição no imperativo.