Após realizarmos a implantação de linting, em nosso último artigo, agora iremos trabalhar na validação desta solução antes de realizarmos a consolidação do commit em nosso repositório com este tutorial de TypeScript.
Confira também as outras postagens desta série de artigos de boas práticas em TypeScript:
- Parte 1: Visual Studio Code como editor de texto padrão do Git
- Parte 2: Comandos Git mais utilizados e como configurar
- Parte 3: O que é Commit e como usar Commits Semânticos
- Parte 4: JavaScript Standard Style: melhores práticas em JS
- Parte 5: Linting em TypeScript com ESLint
TypeScript tutorial parte 6
O que irá garantir que código, que não esteja coerente com as diretrizes definidas, seja persistido em nosso projeto.
Para isso, iremos utilizar o recurso de git hooks, o qual nos permite a execução de algumas tarefas durante o processo de wokflow em eventos do Git.
Mas, o que seriam Git Hooks? São scripts que o Git executa quando uma determinada ação ocorre no repositório. Eles permitem que você automatize tarefas personalizáveis de acordo com o seu workflow de desenvolvimento.
Mas, se hooks é um recurso nativo do Git, por que utilizaremos uma biblioteca para o processo? Por um simples motivo! As configurações dos git hooks ficam dentro do diretório .git/ do projeto.
Esse diretório não é versionado, o que impedi que os hooks sejam compartilhados por um time de desenvolvedores.
Encontre vagas para programador TypeScript
A biblioteca Husky
Para facilitar esse processo utilizaremos o Husky, que é um pacote NPM que expõe uma API para utilizar os hooks do git através de campos de configuração no package.json ou um arquivo específico de configuração.
E assim, permitindo o versionamento dos git hooks utilizados no projeto. Husky não é o único projeto que implementa essa funcionalidade, existem outros, como o Ghooks, mas para esse projeto optamos pelo Husky que supre muito bem nossas necessidades.
https://www.npmjs.com/package/husky
No repositório do projeto no GitHub, podemos visualizar as opções de instalação e configuração da biblioteca.
Entretanto, diferente do demonstrado no exemplo acima, para melhor organização e estrutura do código, não realizaremos a configuração do husky no arquivo package.json, mas criaremos um arquivo específico para os parâmetros que queremos definir para nosso processo de git hooks.
Instalação da biblioteca Husky
Para continuar com o nosso tutorial de TypeScript, vamos instalar a já mencionada biblioteca Husky seguindo o mesmo padrão npm, utilizando a flag -D para que seja instalada somente para nosso ambiente de desenvolvimento, e não sendo replicada no build para o ambiente de produção.
npm install -D husky
Após a instalação, a ferramenta nos permitirá definir um processo de pré-commit, interrompendo o fluxo do evento, possibilitando executarmos scripts antes de persistir as informações do commit.
No caso, poderíamos executar o script de start do ESLint, que configuramos no artigo anterior, o que nos garantiria a validação de nosso código, antes dos arquivos serem commitados, conforme as diretrizes do guide style JS Standard, o que já atenderia nossa necessidade principal.
Contudo, isso nos ocasiona outro problema, se configurarmos o EsLint para ser executado sempre que realizarmos um processo de commit, ele irá realizar uma varredura por todos os arquivos do projeto.
Inicialmente isso não ocasionaria muito impacto, mas, conforme nosso código de desenvolvimento evolui o processo de commit, proporcionalmente, tornaria-se mais lento e oneroso em termos de produtividade.
A biblioteca lint-staged
Para continuar o tutorial de TypeScript com sucesso e resolver a situação podemos utilizar outra biblioteca em conjunto com o Husky, se trata do lint-staged. Essas ferramentas nos permitem definirmos os diretórios os quais estaremos realizando o processo de lint, a cada commit.
E mais do que isso, podemos definir que apenas serão analisados os arquivos que estejam na stage area do Git. Ou seja, somente arquivos adicionados ou alterados desde o último commit serão analisados pelo processo de linting.
Pois, os arquivos commitados anteriormente já passaram por essa validação garantido a consistência na estrutura do seu código.
Isso irá nos assegurar que não teremos perda de performance significativa, mas também mantendo a confiabilidade que as informações persistidas no repositório estão condizente com as diretrizes adotadas pelo pattern.
Para utilizarmos a biblioteca lint-staged, adotamos o mesmo processo habitual de instalação através do npm, apenas como dependência de desenvolvimento.
npm install -D lint-staged
Após a instalação das dependências, podemos realizar as configurações necessárias, para implantarmos a solução que pretendemos. Na raiz do projeto criaremos dois arquivos: huskyrc.json e lintsategdrc.json.
No primeiro, iremos configurar os hooks que iremos utilizar e em quais métodos do Git eles serão executados.
No arquivo lintstagedrc.json, definimos os tipos de arquivos que serão verificados e em quais diretórios eles se encontram.
No arquivo apresentado como exemplo neste tutorial de TypeScript, na imagem ao lado, definimos que a verificação será realizada em todos os arquivos TypeScript (*.ts), que se encontram no diretório (src).
Este diretório, deve ser criado na raiz de nosso projeto, e onde manteremos todo nosso código de desenvolvimento TypeScript. Em conjunto passamos a flag –fix, para que o EsLint tente corrigir automaticamente as incoerências encontradas em nosso código.
Como o lint-staged vasculha astaged area, apenas os arquivos ainda não commitados serão verificados. Isso irá garantir a validação da estrutura de codificação do nosso projeto.
Futuramente quando adotarmos nossos testes unitários (TDD), também poderemos configurar para estes testes serem executados em nosso fluxo de commit, e iremos configurar nestes dois arquivos, a chamada de execução.
Pronto, com estas configurações garantimos a verificação de conformidade do pattern de codificação no processo de pré commit.
Caso exista alguma divergência em nosso código, em relação as normativas determinadas pelo JavaScript Standard Style, e que o ESLint não consiga corrigir através do comando –fix, o workflow do commit será abortado e apresentado as divergências encontradas. Impedindo de consolidarmos código sujo ou não estruturado para o repositório Git.
Para verificarmos a execução do git hook de pré-commit, que acabamos de configurar, vamos realizar o commit dessa nova feature que implantamos.
Lembrando que nesse tutorial de TypeScript que estamos fazendo, optamos pela utilização do conceito de atomic commits (abordado no artigo sobre Commits Semânticos) que devem ser únicos e que implantam apenas um recurso, correção ou atualização.
Neste caso realizaremos um commit do tipo chore (que adiciona um biblioteca ou ferramenta que não será replicada pelo build para produção).
Como ilustração, veja no destaque da imagem acima, que o husky já foi executado no processo de pre-commit, contudo como não possuíamos arquivos do tipo TypeScript em nossa staged area, o processo de lint não foi executado, dando continuidade no fluxo do commit. O que nos garante que nossa implantação já se encontra funcional.
Agora que configuramos a tríade de ESLint, Husky e lint-staged, a equipe de desenvolvimento pode aproveitar os benefícios do novo fluxo de trabalho e incentivar algumas discussões sobre quais novas regras se pode adicionar ao processo de linting para incentivar as melhores práticas.
O código fonte será persistido limpo e estruturado, o que tornará a vida um pouco mais fácil para todos os envolvidos no projeto. Nos próximos artigos quero falar sobre alguns patterns como: Composite, Factory, Builder e Decorator. Até a próxima!!!
Gostou da série de artigos desse grande tutorial de TypeScript? Quero também lhe agradecer pelo seu interesse e incentivo! Ajude a fomentar discussões inteligentes, com comentários, críticas (porque não) e sugestões.
Não esqueça também de deixar seus comentários no post e compartilhar com seus amigos para ajudar esse colega a divulgar seu trabalho.
