Tutorial: linting em TypeScript com ESLint

Com a evolução dos processos de desenvolvimento de código, tornou-se primordial também evoluirmos nas tarefas de automação e aumento de produtividade.

Para isso desenvolvedores devem concentrar uma parte significativa de seu tempo e esforço na configuração de vários tipos diferentes de testes automatizados, que permitem um senso crescente de confiança na qualidade do código. Contudo, ainda não há consistência real com o estilo do código que é enviado para o repositório remoto.

Como iniciativa para melhorar também os processos de validação da estrutura de codificação que está sendo consolidada é necessário avançar no processo de linting de código, introduzindo a imposição automática.

O que deve ajudar os desenvolvedores a evitar o envio de código que não esteja em conformidade com o padrão estabelecido.

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 aderem a determinadas diretrizes de estilo.

O linting moderno de JavaScript também inclui a correção automática de problemas. E uma das ferramentas que permitem esse tipo de verificação é o ESLint, um projeto de código aberto em JavaScript que permite que os desenvolvedores descubram problemas com seu código sem a necessidade de executá-lo.

Por que utilizar lint em seu projeto?

Um projeto deve ter convenções claras e consistentes de codificação, e o uso de uma ferramenta de linting pode ajudar os desenvolvedores a aderir às diretrizes de estilo estabelecidas para a equipe. O uso de linting melhora a qualidade do código e garante que a estrutura do código permaneça consistente e fácil de ler.

A execução do lint antes de qualquer etapa de revisão de código, significa que os desenvolvedores não precisam mais perder tempo considerando a estrutura de código como parte do processo de revisão do código, aumentando a produtividade e possibilitando uma estimativa de “sprint” mais aderente a codificação.

JavaScript Standard Style

Antes, para utilizar o processo de linting, em nosso código, precisamos definir qual style guides estaremos utilizando em nosso projeto.

Para aplicações desenvolvidos em JavaScript temos o pattern Java Script Standard Style, que define diversas práticas de Clean Code na estruturação do código desenvolvido.

Esse artigo tem como base um projeto em TypeScript, que estamos documentando em paralelo com essa série de artigos, o qual iremos exemplificar a implantação do processo de linting.

E como ferramenta de integração do processo de lintcom nosso código, utilizaremos a biblioteca EsLint. Uma ferramenta de análise de código estática, a qual identifica padrões problemáticos encontrados no código JavaScript.

Contudo, apesar do TypeScript ser um superset do JavaScript, ele adiciona diversas funcionalidades que nativamente não estão disponíveis, ou necessitam de várias adequações para utilização. Como tipagem de dados, polimorfismo e Orientação a Objetos.

Desta forma, para que possamos implantar o processo de linting em código Type Script, o EsLint possui um projeto específico que deve ser também instalado, além de outras bibliotecas de apoio.

O projeto se denomina eslint-config-standard-with-typescript, e é mantido no repositório do GitHub, onde existe a documentação necessária para a instalação e configuração.

Como mencionado anteriormente, para utilizarmos o ESLint com Typescript é necessário a instalação de diversas bibliotecas de apoio.

A sintaxe, utilizando o npm, abaixo realiza o processo de instalação das dependências:

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:

1. ESLint;
2. Dependências entre pares do eslint-config-standard;
3. @ typescript-eslint / eslint-plugin;
4. Regras de ESLint para TypeScript.

Plugin EsLint para VSCode

Caso você utilize o VSCode, recomendo fortemente a instalação do plugin EsLint que permite que o IntelliSense do VSCode demonstre os alertas de erros, incluindo as regras que definiremos no arquivo de configuração do EsLint, seguindo as normativas da guia de estilo JS Standard Style.

ESLint: Configuração do Arquivo .eslintrc.json

Para configurar o ESLint é necessário criar um arquivo de configuração chamado .eslintrc.json (esse arquivo pode ter outras extensões como: js e yaml).

O ESLint foi projetado para ser completamente configurável, o que significa que podemos desativar todas as regras e executar apenas com a validação básica de sintaxe, ou misturar e combinar as regras agrupadas e as regras personalizadas para tornar o ESLint adequado a necessidade de nosso projeto. Existem duas maneiras principais de configurar o ESLint:

1. Comentários de configuração – use comentários JavaScript para incorporar informações de configuração diretamente em um arquivo.
2. Arquivos de configuração – use um arquivo JavaScript, JSON ou YAML para especificar informações de configuração para um diretório inteiro e todos os seus subdiretórios. Este arquivo deve ter a nomenclatura de .eslintrc.* . Ou podemos optar por configurar um campo eslintConfig no arquivo package.json. O ESLint irá realizar a busca por estas configurações lendo-as automaticamente.

Para este exemplo utilizaremos a opção de configurarmos manualmente o arquivo estlintrc.json, o que nos permite maior autonomia na configurações das opções e dos parâmetros.

Parâmetros utilizados no ESlint:

Extends: Realiza o extend da biblioteca ESLint, que implanta a análise do style guidesJS Standard Style, definido a estrutura que deve ser utilizada como default;

“extends”: “standard-with-typescript”

ParseOptions: Define para o ESLint que utilizaremos as configurações de publicação(build) que estão 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 requer que qualquer expressão booleana seja limitada a booleanos verdadeiros, em vez de converter outra primitiva em um booleano em tempo de execução.

Es um exemplo de código que estaria incorreto para o processo de linting, pois para essa regra um booleano explícito precisa ser utilizado nestes casos. Desabilitamos essa regra, por acreditar que em diversas situações essa sintaxe é perfeitamente aceitável, e facilitando o processo de Clean Code.

número  const =  0 ; 
if  ( number )  { 
  return ; 
}

“@typescript-eslint/consistent-type-definitions”: “off”

Desabilita a regra a que restringe a utilização dos métodos Interfaces e Types simultaneamente em um mesmo projeto. Essa regra define que deve haver consistência no tipo de definição, sendo necessário a normatização na utilização de um ou de outro em todo o projeto.

Desabilitamos essa regra por entendermos que existe uma diferença semântica entre casos que utilizaremos Interfaces e Types. Mesmo que a execução seja similar e sem comprometimento ao código.

A seguir, dois exemplos distintos que demonstram a diferença na utilização de cada método. No primeiro exemplo, temos a utilização de type, com a finalidade de determinar o tipo do elemento que pode ser usado em outro trecho do código.

No segundo, temos um uso padrão de uma interface a qual define que a classe que implementar essa interface obrigatoriamente necessita implementar a assinatura do método definido.

Uso de Type

type SutTypes = {
 
  sut: EmailValidation
  emailValidatorStub: EmailValidator
}

Uso de Interface

 export interface UpdateAccesTokenRepository {
 
  updateAccesToken (id: string, token:string): Promise<void>
}

Acredito que os dois exemplos deixam claro, que semanticamente o código se torna mais elegante e descritivo, utilizando os dois métodos para situações distintas, ao invés de termos que escolher utilizar um ou outro em nosso projeto.

Simulando Erros de Codificação no Padrão JavaScript Standard Style

Após a instalação e configuração do ESLint, podemos finalmente criar um arquivo de teste e verificarmos o funcionamento de nosso processo de linting.

Na imagem acima, apresentamos como exemplo, a criação de uma função não obedecendo as melhores práticas de codificação definidas no style guides JS Standard Style, abaixo enumeramos estes erros de codificação:

1. O lint identificou que a função deve retornar um elemento, o qual não se encontra definindo em seu tipo de retorno;
2. Outro erro na estrutura de código, é a falta do espaço entre a definição de nomenclatura da função e a abertura dos parênteses;
3. Obedecendo a normatização do pattern, não se utiliza o símbolo “;” como terminador;
4. O ESLint identificou que ao invés de estarmos utilizando indentação com 2 espaços, o código está com indentação de 4 espaços;
5. Outro alerta que o processo de lint nos apresenta é a falta de uma linha em branco ao final do arquivo, o que permite uma melhor visualização do código.
6. Pelo processo de linting, verificou-se que a função declarada não possui nenhuma chamada de utilização dentro do código.

Agora, na imagem abaixo, apresentamos o mesmo código, com as correções propostas pelo pattern JS Standard Style:

1. Realizado a tipagem da função, definindo que ela irá retornar um elemento do tipo number em seu retorno.
2. Colocando o espaço entre o nome da função e os parênteses;
3. Retirado a utilização do símbolo de “;” no final do return;
4. Aplicado o modelo de indentação com 2 espaços em branco;
5. Realizamos a chamada desta função dentro do código;
6. E incluímos uma linha em branco no final do arquivo;

Pronto agora o ESLint, não identifica nenhuma divergência entre a codificação utilizada para esse trecho de código e as normativas definidas pelo pattern utilizado, o StandardJS.

Criar o Arquivo .eslintignore

Para evitar processos de falsos negativos e análises desnecessárias em nosso projeto, iremos utilizar o arquivo de exceção .eslintignore, que segue o mesmo conceito do .gitignore. Que nos permite definir que o nosso processo de linting, não deve se preocupar em analisar a formatação de arquivos dentro destes diretórios

1. node_modules: diretório de bibliotecas de terceiros;
2. dist: diretório de arquivos de publicação com arquivos em JavaScript;
3. coverage: armazena os relatórios de testes gerados pelo Coverage;
4. ./data: diretório que iremos utilizar para manter os dados, quando conteneirizarmos nossa API;
5. requirements: repositório onde manteremos a documentação de nossa API;
6. .vscode: e arquivo de configuração do editor VSCode que utilizaremos quando configurarmos o processo de debug.

Pronto, já temos nosso processo de linting definido em nosso projeto. E para realizarmos um teste de validação de sua implantação, precisamos apenas executar a sintaxe descrita abaixo, que fará uma varredura no diretório src, onde armazenamos todo nosso código de desenvolvimento, em busca de inconformidades com o style guides.

❯ eslint "src/**"

Na imagem acima, verificamos que ESLint identificou divergências em nosso código de desenvolvimento, no caso a já mencionada rule @typescript-eslint/strict-boolean-expressions.

Então, depois de desabilitarmos essa regra no arquivo de configuração eslintrc.json, verificamos que uma nova varredura de linting não mais identificou divergências, atestando que nosso código se encontra dentro das normativas definidas pelo style guides JS Standard Style.

Concluímos esse artigo de implantação do processo de linting, já convidando para a próxima postagem TypeScript tutorial: Validação do processo de linting no pré-commit, onde automatizamos a análise de lint.

Para isso, além do ESlint, usamos outras duas bibliotecas: o Husky e o Lint-Staged, ferramentas que nos permitirão utilizar métodos de Git Hooks para definirmos ações nos processos de pré-commit e push para os repositórios locais e remotos.

Esse processo garantirá a consolidação apenas de códigos normatizados pelo style guides. Até a próxima!!

Se você acompanhou este artigo até aqui, quero lhe agradecer pelo seu interesse e incentivo! Ajude a fomentar discussões inteligentes com comentários, críticas e sugestões. Não esqueça também de compartilhar este artigo.