TypeScript tutorial: Validação do processo de linting no pré-commit

Tendo implementado o linting em nosso último artigo, agora validaremos essa solução antes de confirmar em nosso repositório usando este tutorial do TypeScript.

TypeScript tutorial parte 6

Isso garantirá que o código inconsistente com as diretrizes definidas permaneça em nosso projeto.

Para isso, usaremos o recurso git hooks, que nos permite realizar algumas tarefas durante o processo wokflow dos eventos do Git.

Mas o que seriam os Git Hooks? Esses são scripts que o Git executa quando certas ações ocorrem no repositório. Eles permitem que você automatize tarefas personalizáveis ​​com base em seu fluxo de trabalho de desenvolvimento.

Mas se hooks são um recurso nativo do Git, por que devemos usar uma biblioteca para esse processo? a razão é simples! git hooks são definidos no diretório .git/ do projeto.

Este diretório não é controlado por versão, o que impede que equipes de desenvolvedores compartilhem ganchos.

A biblioteca Husky

Para facilitar esse processo, usaremos o Husky, que é um pacote NPM que expõe uma API para usar git hooks por meio de campos de configuração em package.json ou arquivos de configuração específicos.

Portanto, o controle de versão dos git hooks usados ​​no projeto é permitido. O Husky não é o único projeto que implementa esta funcionalidade, existem outros, como o Ghooks, mas para este projeto escolhemos o Husky e atendeu bem às nossas necessidades.

No repositório do projeto no GitHub, podemos visualizar as opções de instalação e configuração desta biblioteca.

Porém, diferentemente do exemplo mostrado acima, para melhor organização e estrutura do código, não vamos configurar o husky no arquivo package.json, mas sim criar um arquivo específico para os parâmetros que queremos definir para o nosso git hooks process .

Instalação da biblioteca Husky

Para continuar nosso tutorial do TypeScript, instalaremos a biblioteca Husky acima seguindo o mesmo padrão npm, usando o sinalizador -D, para que ela seja instalada apenas para nosso ambiente de desenvolvimento e não copiada para produção em uma compilação.

Uma vez instalada, a ferramenta nos permitirá definir um processo de pré-commit, interrompendo o fluxo de eventos, permitindo executar scripts antes de persistir as informações de commit.

Nesse caso, podemos executar o script de inicialização do ESLint que configuramos no artigo anterior, o que garantirá que nosso código seja validado de acordo com as diretrizes de estilo do JS Standards Guide antes do envio do arquivo, o que já atende às nossas principais necessidades.

Porém, isso nos traz outro problema, se configurarmos o EsLint para executar quando o processo de commit for executado, ele fará uma varredura em todos os arquivos do projeto.

Inicialmente, isso não terá muito impacto, mas à medida que nosso código de desenvolvimento cresce, o processo de confirmação se tornará proporcionalmente mais lento e mais caro em termos de produtividade.

A biblioteca lint-staged

Para continuar com sucesso o tutorial do TypeScript e resolver o problema, podemos usar outra biblioteca com Husky, lint-staged. Essas ferramentas nos permitem definir em cada commit o diretório no qual realizaremos o processo lint.

Não apenas isso, mas podemos definir para analisar apenas os arquivos na área do estágio Git. Ou seja, apenas os arquivos adicionados ou alterados desde o último commit serão analisados ​​pelo processo de linting.

Porque os arquivos enviados anteriormente passaram nessa verificação, garantindo a consistência da estrutura do código.

Isso garantirá que não tenhamos nenhuma perda de desempenho perceptível, mas também manteremos a confiabilidade das informações persistidas no repositório consistentes com as diretrizes adotadas pelo esquema.

Para usar a biblioteca lint-staged, seguimos o mesmo processo de instalação via npm das dependências de desenvolvimento.

Após instalar as dependências, podemos realizar a configuração necessária para implantar nossa solução desejada. No diretório raiz do projeto, criaremos dois arquivos: huskyrc.json e lintsategdrc.json.

Na primeira, vamos configurar os hooks que usaremos e em quais métodos do Git eles serão executados.

lintsategdrc

No arquivo lintstagedrc.json, definimos os tipos de arquivo que serão verificados e os diretórios em que residem.

No arquivo fornecido como exemplo neste tutorial do TypeScript, na imagem ao lado, definimos que todos os arquivos do TypeScript (*.ts) no diretório (src) serão validados.

Este diretório deve ser criado na raiz do nosso projeto, onde manteremos todo o código de desenvolvimento do TypeScript. Passamos o sinalizador –fix juntos para que o EsLint tente corrigir automaticamente as inconsistências encontradas em nosso código.

Quando o lint-staged pesquisa a área de staging, somente os arquivos que não foram confirmados são verificados. Isso garantirá a validação da estrutura de codificação do nosso projeto.

Futuramente quando adotarmos nossos testes unitários (TDD), também poderemos configurar esses testes para serem executados em nosso processo de commit, e configuraremos as chamadas de execução nestes dois arquivos.

Ok, com essas configurações, garantimos que a conformidade do padrão de codificação seja verificada durante o processo de pré-commit.

Se houver alguma divergência em nosso código, relacionada às estipulações determinadas pelo estilo padrão JavaScript, e o ESLint não puder corrigi-las por meio do comando -fix, o fluxo de trabalho de confirmação será abortado e as divergências encontradas serão exibidas. Impede que comitemos código sujo ou não estruturado em um repositório Git.

Para verificar a execução do git hook pre-commit que acabamos de configurar, vamos confirmar esse novo recurso que implantamos.

Lembre-se que neste tutorial de TypeScript que estamos fazendo, optamos por usar o conceito de commits atômicos (abordado no artigo sobre commits semânticos), que deve ser único e implementar apenas um recurso, uma correção ou uma atualização.

Nesse caso, faremos um commit de tipo diverso (que adiciona uma biblioteca ou ferramenta que não será replicada pela compilação para produção).

Atomic-commits

Como ilustração, veja o destaque da imagem acima, husky foi executado durante o processo de pré-commit, mas como não temos arquivos TypeScript em nossa área de teste, o processo lint não é executado e o processo de confirmação continua. Isso garante que nossa implantação já esteja bem executada.

Agora que temos o trio de ESLint, Husky e lint-staged configurados, as equipes de desenvolvimento podem aproveitar o novo fluxo de trabalho e incentivar a discussão sobre quais novas regras adicionar ao processo de lint para incentivar as melhores práticas.

O código fonte será mantido limpo e estruturado, o que facilitará a vida de todos os envolvidos no projeto. Nos próximos artigos, quero discutir alguns padrões como: Composto, Fábrica, Construtor e Decorador. para o próximo! ! !

Você gostou da série de artigos neste incrível tutorial do TypeScript? Agradeço também a atenção e incentivo! Ajude a promover uma discussão informada com comentários, críticas (por que não) e sugestões.