O Problema

Todos nós verificamos a formatação, testamos e deixamos nosso código organizado. Isso é algo que, em poucas palavras, facilita nossas vidas, torna as solicitações de pull mais legíveis e torna todo o código consistente em uma base de código. Normalmente, essas tarefas são executadas em algum tipo de pipeline de CI e, ocasionalmente, esquecemos de executá-las localmente antes de enviar as alterações. Como resultado, achamos que terminamos de escrever a funcionalidade, apenas para descobrir que nossa ação do GitHub falhou. Descobrimos que a verificação de código falhou ou que um teste que foi afetado agora está quebrado. Ou ainda, a formatação está inconsistente em um dos arquivos que editamos.

Bom saber

Este artigo pressupõe que você esteja familiarizado com o eslint, prettier e jest. Além disso, é necessário ter conhecimento em git.

A Solução

Existem três partes na nossa solução:

• Configurar os comandos apropriados no package.json
• Configurar o lint-staged (mais sobre isso depois)
• Configurar o husky

Parte 1: Configurando os comandos apropriados

O package.json é onde todos os nossos comandos estão armazenados. Agora, como mencionado na introdução, frequentemente queremos executar a verificação de código, teste e formatação do nosso código antes de mesclá-lo na brach principal. Isso significa que precisamos ter pelo menos esses 3 comandos em nosso arquivo:

• "lint": "eslint" executará a verificação de código para o nosso projeto e garantirá que não quebramos nenhuma regra.
• "prettify": "prettier --write" executará o prettier em nosso projeto e garantirá que todos os arquivos estejam formatados corretamente. Consistência, consistência, consistência
• "test:changed": "jest --onlyChanged" tentará identificar quais arquivos foram alterados e, com base nisso, quais testes são afetados (precisa do gráfico de dependência). Em seguida, executará esses testes.

Parte 2: Configurando o lint-staged

O lint-staged é uma ferramenta notável. Ele permite que você execute automaticamente scripts em um subconjunto dos arquivos que está prestes a confirma, aqui está um exemplo de arquivo .lintstagedrc:

{
    "*.+(ts|html)": [
      "eslint"
    ],
    "*.{js,ts,html,css,scss}": [
      "prettier --write"
    ],
    "*.spec.ts": [
      "jest --findRelatedTests"
    ]
}

Já que os comandos são bastante simples, eu pulei a parte de usar npm run. Aqui está uma breve explicação do que está acontecendo no arquivo:

Selecionamos todos os arquivos com extensão .ts ou .html e executamos o eslint neles. Selecionamos todos os arquivos com extensão .js, .ts, .html, .css ou .scss e executamos o prettier --write neles. Selecionamos todos os arquivos que terminam com .spec.ts e executamos o jest --findRelatedTests neles. Isso significa que executaremos todos os testes nesses arquivos. Mais sobre isso depois. Legal! Agora temos uma configuração adequada para o lint-staged. Estamos quase lá.

Parte 3 - Configurando o husky

Parte 3 - Configurando o husky Não, não é o cão. husky é uma ferramenta que permite executar comandos pré-commit e pré-push (entre outras coisas). Mais informações sobre o husky. Para nossa configuração, teremos 2 novos arquivos. O primeiro será o .husky/pre-commit. Ele terá apenas 1 linha:

npx lint-staged

Isso é tudo. Isso garantirá que toda vez que você tentar fazer um commit, este comando será executado, que por sua vez iniciará o processo de lint-staged que configuramos acima. Em detalhes, isso significa que antes de o comando de commit ser concluído, os comandos eslint, prettier --write e jest --findRelatedTests precisam passar.

Mas isso não é tudo, apenas para ter uma confiança extra, podemos configurar um hook pre-push. Fazemos isso criando um novo arquivo: .husky/pre-push. Este também é um comando de uma linha:

npm run test:changed

Isso garantirá que, quando você estiver tentando fazer push, todos os testes estejam saudáveis. Para fazer isso de maneira eficiente, ele usará o gráfico de dependência e tentará identificar todos os testes que precisam ser executados com base nos arquivos alterados.

Parte 4 - Esclarecimentos

Eu sei, eu sei, a etapa 4 não fazia parte do plano. Eu só queria ter certeza de que as coisas estavam um pouco mais claras.

Em primeiro lugar, você precisará instalar essas ferramentas. Você precisará executar:

npm install husky --save-dev

npm install --save-dev lint-staged

Apenas para esclarecer.

Para testes, você percebeu que temos 2 tipos: --findRelatedTests e --onlyChanged. Eu não fiz muita pesquisa sobre esses comandos, mas aqui está o que entendi.

• --findRelatedTests precisa de uma lista de arquivos como argumento, não faz nenhuma análise estática e executa todos os testes nos arquivos passados. Isso é usado com o lint-staged para garantir que executemos todos os testes que foram alterados ou adicionados. Novamente, a única informação necessária para isso é: quais arquivos .spec.ts fazem parte do commit.
• --onlyChanged precisa fazer uma análise estática do projeto. Ele usará essa informação, juntamente com a lista de arquivos que mudaram (todos os arquivos, não apenas os arquivos .spec.ts), para descobrir quais testes precisam ser executados novamente. Por exemplo, digamos que você tenha alterado o button.component.ts. Isso significa que você pode ter afetado os testes em button.component.spec.ts, mesmo que aquele arquivo não tenha mudado. Essa situação será detectada pelo comando --onlyChanged, mas será perdida pelo comando --findRelatedTests. Espero que isso esclareça as coisas um pouco.