O cavalo está morto - cry: transição de tslint para eslint

Até recentemente, em todos os projetos da frente, os desenvolvedores da Dodo Pizza Engineering usavam o tslint - uma ferramenta útil que informa quando você estraga o código, faz imprecisões, ajuda a manter o código no mesmo estilo e corrige muitos comentários. Mas então o tslint tomou e morreu. Por baixo do corte, vou lhe dizer por que isso aconteceu, como parar de derramar lágrimas sobre o falecido e mudar para a ferramenta de limpeza, além de mostrar algo muito íntimo.



De fato, tudo começou há muito tempo: a última versão do kernel tslint já estava em 2016. E este é o momento em que é hora de começar a dizer "último", se alguém ainda diz "último", porque esse lançamento foi realmente o último. Em 19 de fevereiro de 2019, um post oficial foi lançado para interromper o desenvolvimento do tslint. Nele, a empresa de desenvolvimento (a propósito, nem mesmo é a Microsoft) aconselha todos a mudar para o eslint, já que seus esforços agora serão direcionados para melhorar o suporte ao TypeScript neste linter.

Um idioma, uma pilha, uma comunidade

A Microsoft vê o TypeScript como a principal linguagem de desenvolvimento da web, que deve suplantar o Java / ECMA Script. Obviamente, um objetivo tão ambicioso implica uma única pilha de ferramentas para todo o desenvolvimento front-end. Isso deve simplificar bastante a migração da grande comunidade JS para o TypeScript. Além da garantia de confiança da Microsoft, o eslint possui uma arquitetura melhor que o tslint. Por exemplo, você pode conectar analisadores e há mais opções de regras conectadas.

A Microsoft não seria ela mesma se fosse apenas desejada. O que dissermos sobre a qualidade de seu software, eles fazem ótimas ferramentas de desenvolvimento (e, a propósito, dispositivos de entrada). Dessa vez, eles não chegaram de mãos vazias, mas escreveram um plano de migração . De acordo com este plano, o desenvolvimento das regras do tslint já foi descontinuado em 1 de agosto de 2019 e o desenvolvimento do próprio tslint cessará em 1 de novembro de 2019. Embora, para ser sincero, o desenvolvimento tenha sido interrompido há muito tempo (veja a versão mais recente acima).

Aqui, deve ficar óbvio para o leitor que é hora de mudar para o eslint, não há outra escolha. Para adoçar a pílula, vale dizer que:

• enquanto o tslint é focado no TypeScript, com maior ênfase no uso correto de tipos e na verificação de sintaxe, o eslint cobre tudo o que pode estar à frente, incluindo a sintaxe dos componentes do React;
• eslint tem muito mais regras predefinidas;
• existem regras (e plugins) que verificam o código no nível do bloco (duplicação de código, complexidade percebida etc.);
• existem plugins que não verificam código, mas, por exemplo, expressões regulares.

Em geral, parece que a transição para um novo linter, que é um produto convencional, abrirá um mundo inteiro de oportunidades nunca vistas antes. Bem, vamos tentar!

Adicionar eslint ao projeto

Vou falar sobre a migração de regras abaixo. Enquanto isso, configure um projeto para trabalhar com o eslint.
Se você já possui um projeto com o tslint, primeiro remova todos os pacotes relacionados ao tslint: o próprio tslint, tslint-react, tslint-config-prettier, etc.

Agora adicione pacotes eslint ao projeto (defina tudo como devDependencies):

• eslint em si;
• @ typescript-eslint / parser - mecanismo para analisar o TypeScript;
• @ typescript-eslint / eslint-plugin - conjuntos de regras para o TypeScript

Configuração mínima do Eslint

Crie o arquivo de configuração .eslintrc.json. O Eslint suporta muitos formatos de arquivo para sua configuração, mas o JSON parece o mais conveniente. Aqui está a aparência da opção mínima de trabalho:

{ //   "env": { //    "browser": true, //   ES6 "es6": true, //   ES2017 "es2017": true }, //   "extends": [ //    eslint "eslint:recommended", //      "plugin:@typescript-eslint/eslint-recommended", //    TypeScript "plugin:@typescript-eslint/recommended", //  TS,     "plugin:@typescript-eslint/recommended-requiring-type-checking" ], //   "parser": "@typescript-eslint/parser", "parserOptions": { //    TS     "project": "tsconfig.json", "tsconfigRootDir": ".", }, //      TypeScript "plugins": ["@typescript-eslint"], "rules": {} } 

A seção env informa a eslint sobre as opções do seu projeto. No meu exemplo, este é um projeto para o navegador (ou seja, o código funcionará no navegador). Escreva para Node.JS - set node: true. As duas opções a seguir indicam o dialeto do JS sendo testado. Em geral, verificaremos o código para o TypeScript, mas se o seu projeto também tiver código para JS, não esqueça de apertá-lo. Por nós mesmos, decidimos definir esses parâmetros com o mesmo valor que o destino no tsconfig.json.

Não há nada polêmico nos conjuntos de regras padrão de eslint, como o ponto e vírgula necessário no final de expressões ou espaços / guias. Todas as regras são exclusivamente úteis. Você pode ver quais regras e com qual nível estão incluídos aqui .

Na próxima linha, você precisa desativar metade das regras. Isso é necessário porque eles não funcionam com o TypeScript e, em vez de funcionar normalmente, geram vários erros.

Em seguida, conecte as regras recomendadas do TypeScript em um pacote separado. Aqui você deve ter em mente que regras gerais de sintaxe (como banir var) funcionarão assim.

Porém, para regras que usam tipos TS (por exemplo, @ typescript-eslint / asserção de tipo desnecessária), o mecanismo TypeScript é necessário. E o mecanismo precisará do arquivo tsconfig.json, o caminho para o qual deve ser especificado.

No tsconfig.json, nós da Dodo Pizza Engineering normalmente especificamos excluir e executar testes para que eles não sejam construídos com o projeto. Mas para que o eslint funcione, você deve especificar e incluir. Ou seja, todos os arquivos que precisam ser identificados devem ser incluídos explicitamente no projeto. Sem isso, o eslint xingará em todos os arquivos que encontrar: "O arquivo não está no projeto, não farei nada, lançarei vários erros". Existe uma opção sem especificar explicitamente os arquivos do projeto - defina o parâmetro createDefaultProgram: true . Isso, em essência, significa: "Tudo o que você encontra é Parsi". Mas os desenvolvedores desaconselham fortemente fazê-lo por causa de uma queda significativa no desempenho.

Se você usar o ForkTsCheckerWebpackPlugin para processar arquivos TypeScript, substitua tslint: true por eslint: true em seus parâmetros (em webpack.config.ts).

Também vale a pena configurar o lançamento do linter a partir da linha de comando. Antes disso, adicione esse valor à seção de scripts em package.json :

 "eslint": "eslint --cache --ext .js,.jsx,.ts,.tsx src", "eslint:dump": "eslint --print-config ./.eslintrc.json", 

A primeira linha apenas inicia a verificação do eslint sem criar o projeto. O segundo exibe as configurações atuais do eslint, que permitem ver as configurações dos parâmetros da regra.

Nesta versão, o eslint já funcionará no projeto e até pegará alguns cardumes: redefinindo globais, variáveis ​​não utilizadas etc.

Configurando o código do Visual Studio

Depois de percorrer todo esse caminho, você já pode iniciar o linter a partir da linha de comando. Ele também será lançado implicitamente ao criar o projeto. Mas no Visual Studio Code, não veremos comentários do linter. Como assim ?!

Existe um plugin eslint para o estúdio (dbaeumer.vscode-eslint), ele precisa ser instalado. Depois disso, nada funcionará de qualquer maneira, nada será enfatizado e corrigido. Porque Como o plug-in tem uma configuração, o que diz que você precisa trabalhar apenas em arquivos JavaScript.

Essa configuração sorrateira não é feita na interface do usuário; portanto, você precisa acessar o arquivo de configurações do estúdio e adicionar manualmente os idiomas necessários ao parâmetro eslint.validate. Uma lista completa de idiomas pode ser encontrada nas entranhas da documentação do estúdio. Aqui está a aparência dessa configuração conosco:

 "eslint.validate": [ "javascript", "javascriptreact", "typescriptreact", "typescript", ], 

Depois disso, reinicie o estúdio e tudo finalmente começará a funcionar.

Agora resta configurar as regras

O projeto está configurado. Agora sobre as regras, porque no exemplo acima a lista de regras estava vazia.

Devo dizer que o tslint não nos impediu de estragar o código formalmente correto. Por exemplo, esqueça de aguardar. Eslint é capaz de encontrar esses erros semânticos e jurá-los: informar que o valor de retorno é Promessa, mas, por algum motivo, aguardar não está escrito. Isso também inclui problemas estilísticos de média complexidade: o uso de uma função ou lambda etc., que Prettier não pode mais fazer.

Em relação a regras simples: posição entre parênteses, tabulações vs. espaços, etc., acredita-se que devam ser dados à Prettier ou a um pacote similar. Mas, no linter, eles devem ser deixados de qualquer maneira: esta é a última fronteira, que ainda é capaz de parar o desenvolvedor negligente da montagem do projeto caída. Além disso, essa linha pode ser automatizada: por exemplo, rouca , permite iniciar o linter automaticamente para cada confirmação.

Decidimos não migrar nenhum dos conjuntos de regras tslint que possuímos. E crie seu próprio conjunto do zero.

Existem conjuntos de regras predefinidos para o eslint:

• O ESLint Recommended é um conjunto neutro de regras que é feito com a idéia de não gerar holivares. Apenas as verificações obviamente necessárias estão incluídas: variáveis ​​não utilizadas, etc. Todos os conjuntos subsequentes estendem esse.
• Google - já existe uma razão para o holivar: para o recuo, existem estritamente espaços, é necessário um ponto e vírgula.
• AirBnB - Também existem regras rígidas de estilo, incluindo um ponto e vírgula obrigatório.
• Padrão - ponto e vírgula é proibido aqui, mas vírgulas finais também são proibidas.

Não gostamos de nenhum dos pacotes prontos. Isso pode parecer estranho, mas é importante mudar para um novo linter, evitando guerras estilísticas. Se escrevermos assim em todos os lugares (guias, sem ponto e vírgula, vírgulas finais são obrigatórias), deixe que continue assim - o principal é que é o mesmo em todos os projetos.

Sexo prometido: seu próprio conjunto de regras

Honestamente, mostrar seu conjunto de regras eslint é como uma garota mostrando peitos: não há mais segredos. Pensei por muito tempo se vale a pena fazer isso. Mas, depois de consultar as colegas, decidi que valia a pena.

Vou começar com os plugins que usamos:

• react - verifica o código do componente react. Conjunto básico de regras mais o nosso. Do importante: nos afogamos em componentes funcionais puros;
• react-hooks - regras dos desenvolvedores do react sobre o uso de hooks;
• promessa - verifica se há erros comuns ao usar o Promise. Isso funciona um pouco estranho com o código TypeScript. Do importante: tentamos usar o Promise em qualquer lugar e não usamos retornos de chamada e / catch por causa da melhor legibilidade do código;
• optimize-regex é um plugin divertido que fornece dicas sobre como melhorar expressões regulares. Não é muito útil, porque regexp temos um pouco. Mas longe de tudo possuem a magia regexp. Portanto, é útil, mas não há muita pergunta;
• sonarjs é um plug-in de incêndio com verificações de complexidade de código e erros típicos de refatoração. A primeira é uma coisa engraçada: o plug-in avalia a complexidade percebida do código e dá conselhos quando vale a pena simplificar o código. A busca por erros de refatoração geralmente também permite simplificar o código ou, pelo menos, melhorar a legibilidade;
• @ typescript-eslint - regras de eslint para verificar o código TypeScript. E um conjunto para desativar regras básicas que não são compatíveis com o TS.

Todo o nosso arquivo de regras está aqui . Observo que não é um dogma e é atualizado à medida que se adapta aos projetos.