Pular para o conteúdo principal

Angular e Lint: Análise de código

 


A plataforma Angular costuma primar pelas boas práticas, sempre recomendando-as e reforçando-as em sua arquitetura. Um dos conceitos utilizados é o de lint, termo que ficou popular recentemente e que indica uma análise estática do código-fonte em busca de violações: no estilo, formato e em construções suspeitas.

O conceito de lint não é novo: foi criado no final dos anos 70 (Wikipedia), para a linguagem C, e vem evoluindo desde então com ferramentas diversas para as mais variadas linguagens de programação. Na plataforma Angular, a ferramenta TSLint foi adotada desde as primeiras versões, fornecendo análises estáticas para manter o código desenvolvido mais robusto e padronizado entre as equipes. Quando criamos uma aplicação Angular a partir da ferramenta de linha de comando (@angular/cli), um comando é adicionado no arquivo package.json para realizar uma análise no código do projeto: ng lint. A saída do comando aponta possíveis violações nos padrões de projeto e nas convenções definidas para a aplicação. Até recentemente, este era o padrão adotado para os projetos Angular.

Acontece que, em 2019, a equipe que desenvolve o TSLint (principalmente, a empresa Palantir Technologies) resolveu descontinuá-lo em favor de uma unificação em torno de outra ferramenta: ESLint, que já vinha sendo muito utilizada para projetos Javascript. Uma boa iniciativa para facilitar a vida de ambas as comunidades de programadores e também um passo facilitado rumo a uma migração dos desenvolvedores Javascript para uma linguagem tipada como o Typescript.

E como se posicionou a comunidade Angular? Simples, apoiou a decisão e forneceu os meios para que os aplicativos Angular pudessem migrar para a nova ferramenta padrão, o ESLint. E esta é uma migração bem facilitada. Vamos aos passos:

1 - Instalar a nova ferramenta. Utilizar a linha de comando é o melhor modo

ng add @angular-eslint/schematics

2 - Com a ferramenta instalada, devemos utilizá-la para converter o nosso projeto para passar a utilizá-la. Novamente, a linha de comando nos auxilia

ng g @angular-eslint/schematics:convert-tslint-to-eslint <nome-projeto>

3 - Pronto, o ESLint está instalado e configurado para o projeto. Agora, podemos remover o TSLint. Devemos remover o arquivo tslint.json e também os aplicativos tslint e codelizer (aqui, utilizamos o npm - npm remove tslint e npm remove codelyzer).

Para você que está utilizando o Angular, o lint é algo altamente recomendável - faz você seguir os melhores padrões definidos pela equipe que desenvolveu a ferramenta, e te permite manter um alto padrão de qualidade. Altamente recomendável!!


Comentários

Postagens mais visitadas deste blog

Jakarta EE 10, A nova versão corporativa do Java

Mais de um ano atrás, fiz um post sobre o lançamento da versão 9.1 do Jakarta EE (confira esse post aqui ). Nesse post, eu expliquei um pouco sobre a transferência do Java EE da Oracle para a Eclipse Foundation e a mudança necessária ocorrida nessa versão no nome dos pacotes: de javax para jakarta . Agora, acabou de sair uma nova versão do Jakarta EE , versão 10 , a primeira versão que verdadeiramente traz novidades nas especificações que tanto conhecemos: JPA agora evoluiu para a versão 3.1; CDI para a versão 4.0; JAX-RS  para a versão 3.1; e assim por diante. Foram mais de vinte especificações atualizadas / evoluídas nesta versão, que criou também um novo perfil de implementação. Agora, temos três perfis para implementação do Jakarta EE :  Jakarta EE 10 Platform , o perfil completo com todas as especificações (este perfil somente os servidores de aplicação costumam implementar, como Wildfly e Glassfish ); Jakarta EE 10 Web Profile , um perfil com especificações volta...

Maven - Versão nova lançada

  Saiu versão nova do Maven - 3.8.2. Esta foi apenas uma versão de correção de bugs, mas a versão anterior, a 3.8.l, foi uma versão importante e vou aproveitar para falar sobre ela. Quem acompanha o histórico de versões do Maven , deve ter percebido o pulo de versão, da 3.6.3 para esta 3.8.1. A razão está explicada neste link , e o grande motivo foi tentar evitar problemas de segurança pelo acesso a repositórios via protocolo HTTP. Por default, esta versão 3.8.1 do Maven bloqueia o acesso a repositórios HTTP - você precisa acessar repositórios HTTPS . O bloqueio acontece com a adição de um mirror chamado "maven-default-http-blocker", bloqueando todo e qualquer acesso a repositórios HTTP externos. <mirror>    <id>maven-default-http-blocker</id>    <mirrorOf>external:http:*</mirrorOf>   <name>Pseudo repository to mirror external repositories initially using HTTP.</name>    <url>http://0.0.0.0/</u...

Implantando o Flyway em sistemas Java - Parte 1

  Quando temos uma empresa terceirizada de fábrica de software desenvolvendo, geralmente especificamos no edital de licitação que essa empresa precisa entregar alguns artefatos obrigatórios para poder receber pelos serviços prestados: o código-fonte (óbvio!), diagramas UML (quando necessário), evidências de testes (artefato que cada vez mais me convenço que de nada serve)... e um plano de implantação. Esse plano de implantação precisa trazer os passos necessários para colocar o produto no ambiente de homologação (e, posteriormente, no ambiente de produção). Na maioria das vezes, um ou mais scripts de banco de dados que devem ser executados. Nós, servidores, tínhamos que abrir o plano de implantação, verificar os passos, acessar o versionador, abrir a ferramenta de banco de dados, copiar o(s) script(s), executá-los, tudo manualmente, gerando um trabalhinho chato e propenso a erros. Além disso, os scripts sempre ficavam meio perdidos: as vezes espalhados por pastas relativas às orden...