Tutorial: linting em TypeScript com ESLint
À medida que o processo de desenvolvimento de código evolui, também evolui a evolução das tarefas automatizadas e o aumento da produtividade.
Para fazer isso, os desenvolvedores devem concentrar a maior parte de seu tempo e esforço na configuração de vários tipos diferentes de testes automatizados que aumentam a confiança na qualidade do código. No entanto, ainda não há consistência real no estilo de código enviado para repositórios remotos.
Como iniciativa para melhorar o processo de verificação da estrutura de codificação que está sendo integrada, é necessário avançar no processo de revisão de código e introduzir a execução automática.
Isso deve ajudar os desenvolvedores a evitar o envio de código que não atenda aos padrões estabelecidos.
O que é o linting?
Linting é o processo de aplicar regras a uma base de código e destacar padrões ou códigos problemáticos que não estão em conformidade com certas diretrizes de estilo.
O linting JavaScript moderno também inclui correções automáticas de bugs. Uma das ferramentas que permite esse tipo de verificação é o ESLint, um projeto JavaScript de código aberto que permite aos desenvolvedores descobrir problemas com seu código sem precisar executá-lo.
Por que utilizar lint em seu projeto?
Um projeto deve ter convenções de codificação claras e consistentes, e o uso de ferramentas de linting pode ajudar os desenvolvedores a aderir às diretrizes de estilo de equipe estabelecidas. O uso de linting melhora a qualidade do código e garante que a estrutura do código seja consistente e fácil de ler.
Executar o lint antes de qualquer etapa de revisão de código significa que os desenvolvedores não precisam mais perder tempo pensando na estrutura do código como parte do processo de revisão de código, aumentando a produtividade e permitindo melhores estimativas de sprint para o processo de revisão de código.
JavaScript Standard Style
Antes, para usar o processo de linting em nosso código, precisamos definir o guia de estilo que usaremos em nosso projeto.
Para aplicações desenvolvidas em JavaScript, temos o padrão Java Script Standard Style, que define várias práticas de código limpo para estruturar o código desenvolvido.
Este artigo é baseado em um projeto TypeScript que documentaremos paralelamente a esta série de artigos, nos quais ilustraremos a implementação do processo de linting.
Como ferramenta para integrar o processo lint ao nosso código, utilizaremos a biblioteca EsLint. Uma ferramenta de análise de código estático que identifica padrões problemáticos encontrados no código JavaScript.
No entanto, embora o TypeScript seja um superconjunto de JavaScript, ele adiciona alguns recursos que não estão disponíveis nativamente ou exigem várias modificações para serem usados. Como tipos de dados, polimorfismo e orientação a objetos.
Assim, para que possamos implementar o processo de linting em nosso código TypeScript, o EsLint possui um projeto específico que deve ser instalado além de outras bibliotecas de suporte.
O projeto é chamado eslint-config-standard-with-typescript e é mantido em um repositório GitHub com a documentação necessária para instalação e configuração.
Como mencionado anteriormente, para usar o ESLint com Typescript, você precisa instalar várias bibliotecas de suporte.
O seguinte usa a sintaxe do npm para executar o processo de instalação de dependência:
npm install --save-dev eslint@6 eslint-plugin-standard@4 eslint-plugin-promise@4 eslint-plugin-import@2 eslint-plugin-node@11 @typescript-eslint/eslint-plugin@2 eslint-config-standard-with-typescript
Sim, eu sei que é um grande número de pacotes. Isso ocorre devido a uma limitação conhecida no ESLint.
Essa longa lista de dependências inclui:
ESLint;
Dependências entre pares do eslint-config-standard; @ typescript-eslint / eslint-plugin; Regras de ESLint para TypeScript. eslint javascript standard style
Plugin EsLint para VSCode
Se você usa o VSCode, recomendo instalar o plugin EsLint, que permite ao VSCode IntelliSense exibir alertas de erro, incluindo regras que definiremos no arquivo de configuração do EsLint, seguindo o guia de estilo padrão JS.
ESLint: Configuração do Arquivo .eslintrc.json
Para configurar o ESLint, você precisa criar um arquivo de configuração chamado .eslintrc.json (este arquivo pode ter outras extensões como: js e yaml).
O ESLint foi projetado para ser totalmente configurável, o que significa que podemos desabilitar todas as regras e executar apenas com validação de sintaxe básica, ou misturar e combinar agrupamento e regras personalizadas para que o ESLint atenda às necessidades do nosso projeto. Existem duas maneiras principais de configurar o ESLint:
Comentários de configuração – Use comentários de JavaScript para incorporar informações de configuração diretamente nos arquivos.
Arquivos de configuração – Use arquivos JavaScript, JSON ou YAML para especificar informações de configuração para todo o diretório e todos os seus subdiretórios. Este arquivo deve ser nomeado .eslintrc.* . Ou podemos optar por configurar um campo eslintConfig no arquivo package.json. O ESLint procurará essas configurações lendo-as automaticamente.
Neste exemplo, usaremos a opção de configurar manualmente o arquivo estlintrc.json, o que nos dá mais autonomia na configuração de opções e parâmetros.
Parâmetros utilizados no ESlint:
Extends: Estende a biblioteca ESLint, implementa a análise do estilo padrão guidesJS e define a estrutura que deve ser usada por padrão;
“extends”: “standard-with-typescript”
ParseOptions: Para definir para ESLint, usaremos as configurações de publicação (build) definidas no arquivo tsconfig.json;
“parserOptions”: {“project”: “./tsconfig.json”}
Rules: Definimos regras que estaremos desabilitando em nosso processo de lint, as quais não são coerentes com a arquitetura de projeto que estamos desenvolvendo.
“@typescript-eslint/strict-boolean-expressions”: “off”
Essa regra exige que qualquer expressão booleana seja limitada a valores booleanos verdadeiros, não convertendo outra primitiva em um valor booleano em tempo de execução.
Este é um exemplo de código incorreto para o processo de linting, pois para esta regra é necessário um valor booleano explícito nestes casos. Desativamos essa regra porque acreditamos que essa sintaxe é perfeitamente aceitável em muitos casos e ajuda a limpar o processo de código.
número const = 0 ; if ( number ) { return ; } “@typescript-eslint/consistent-type-definitions”: “off”
Desabilita a regra que restringe o uso de métodos de interface e de tipo no mesmo projeto. Essa regra define que os tipos de definição devem ser consistentes, o que é necessário para padronizar o uso de um ou outro ao longo do projeto.
Desabilitamos essa regra porque sabemos que há uma diferença semântica entre os casos em que usaremos interfaces e tipos. Mesmo que a execução seja semelhante e não afete o código.
Abaixo estão dois exemplos separados mostrando a diferença no uso de cada método. No primeiro exemplo, usamos tipos para determinar os tipos de elementos que podem ser usados em outra parte do código.
Segundo, temos um uso padrão de uma interface, que define a assinatura do método definido que uma classe que implementa essa interface deve implementar.
Uso de Type
type SutTypes = { sut: EmailValidation emailValidatorStub: EmailValidator }
Uso de Interface
export interface UpdateAccesTokenRepository { updateAccesToken (id: string, token:string): Promise<void> }
Acredito que esses dois exemplos mostram claramente que semanticamente o código fica mais elegante e descritivo, usando as duas abordagens em situações diferentes sem ter que optar por usar uma ou outra em nosso projeto.
Simulando Erros de Codificação no Padrão JavaScript Standard Style
Depois de instalar e configurar o ESLint, podemos finalmente criar um arquivo de teste e verificar se nosso processo de linting está funcionando.
Na imagem acima, mostramos como exemplo a criação de uma função que não segue as melhores práticas de codificação definidas no guia de estilo padrão JS, e abaixo listamos esses erros de codificação:
Lint identifica que a função deve retornar um elemento não definido em seu tipo de retorno;
Outro bug na estrutura do código é a falta de espaço entre a definição nomeada da função e o início dos parênteses;
Siga a especificação do padrão e não use o símbolo “;”. como terminador;
O ESLint descobriu que o código não estava recuado com 2 espaços, mas com 4 espaços;
Outro alerta que o processo lint nos lança é a falta de linhas em branco no final do arquivo, o que permite uma melhor visualização do código.
Através do processo de linting, verifica-se que a função declarada não possui nenhuma chamada de uso no código.
Agora, na imagem abaixo, mostramos o mesmo código, com as correções propostas pelo padrão de estilo JS:
eslint
Realiza a digitação da função, definindo que ela retornará um elemento do tipo número em seu retorno.
coloque um espaço entre o nome da função e os parênteses;
Removido o uso do símbolo “;” no final do retorno;
aplique um modelo de recuo com 2 espaços;
Chamamos essa função em nosso código;
Incluímos uma linha em branco no final do arquivo;
Agora, o ESLint não encontrou nenhuma diferença entre a codificação usada para esse trecho de código e as regras definidas pelo padrão StandardJS usado.
Criar o Arquivo .eslintignore
Para evitar processos de falsa negação e análises desnecessárias em nosso projeto, usaremos o arquivo de exceção .eslintignore, que segue os mesmos conceitos do .gitignore . Isso nos permite definir que nosso processo de linting não deve se preocupar em analisar o formato dos arquivos nesses diretórios
node_modules: diretório de bibliotecas de terceiros;
dist: diretório de arquivos de publicação com arquivos em JavaScript;
coverage: armazena os relatórios de testes gerados pelo Coverage;
./data: diretório que iremos utilizar para manter os dados, quando conteneirizarmos nossa API;
requirements: repositório onde manteremos a documentação de nossa API;
.vscode: e arquivo de configuração do editor VSCode que utilizaremos quando configurarmos o processo de debug.
Ok, definimos o processo de linting no projeto. Para fazer um teste de validação de sua implementação, basta executar a sintaxe descrita abaixo, que irá escanear o diretório src onde todo o nosso código de desenvolvimento está armazenado para não conformidade com o guia de estilo.
❯ eslint "src/**"
Na imagem acima, podemos ver que o ESLint identificou divergências em nosso código de desenvolvimento, neste caso a regra acima @typescript-eslint/strict-boolean-expressions.
Portanto, após desabilitar esta regra no arquivo de configuração eslintrc.json, verificamos que a nova varredura de linting não identifica mais divergências, comprovando que nosso código está em conformidade com as especificações definidas pelo guia de estilo JS Standard Styles.
Concluímos este artigo de implantação do processo de lint e convidamos você para a próxima postagem do tutorial do TypeScript: Validando processos de lint em pré-commit, onde automatizamos a análise de lint.
Para isso, além do ESlint, usamos outras duas bibliotecas: Husky e Lint-Staged, essas ferramentas nos permitirão definir ações em pre-commits e processos de push para repositórios locais e remotos usando métodos Git Hooks.
Esse processo garantirá que apenas o código padronizado pelo guia de estilo seja mesclado. para o próximo!!
Se você tem acompanhado este artigo até agora, gostaria de agradecer sua atenção e incentivo! Ajude a desencadear discussões inteligentes com comentários, críticas e sugestões. Não se esqueça de compartilhar este artigo também.