Há algum tempo, troquei o projeto de JSHint para ESLint (este último sendo melhor mantido e oferecendo mais recursos). No entanto, defini muitas das configurações como avisos porque não tive tempo para resolver os problemas potenciais. Nem tive tempo de ajustar as configurações que tornam o código mais fácil de manter.
Portanto, a tarefa seria essencialmente olhar para os avisos ESLint e ver o que pode ser tratado com segurança. (Por exemplo, muitos dos ==
avisos de igualdade podem não ser "corrigíveis" para ===
sem testar cada valor que passa por essa verificação.) Seria útil também definir avisos para coisas a serem tratadas no futuro / em andamento, como a aplicação da documentação JSDoc.
Olá, gostaria de agarrar isto!
@umuur Vá em frente!
@ matthew-dean Queremos manter a configuração eslint atual?
Não tenho certeza se o TypeScript como analisador e plug-in é necessário.
@umuur
Queremos manter a configuração eslint atual?
Depende. Se você quiser fazer alterações que não mudem a formatação do código, tudo bem. Mas, no que diz respeito aos avisos, IMO, todos são avisos válidos e queremos resolvê-los ou deixar um comentário sobre o código do eslint desativado e (o mais importante ) por que ele não é válido lá.
Queremos manter a configuração eslint atual?
Mesmo que a base de código ainda não use o TypeScript, na minha experiência, ela faz um trabalho melhor transpilando do que o Babel. Em termos de ESLint ... 🤔 sim, você está certo, não é tecnicamente necessário até que haja código no TypeScript. Provavelmente fiz isso antes de converter a base de código para TS, mas agora não sei se / quando isso vai acontecer.
@umuur
A propósito, em qualquer lugar onde você possa adicionar comentários JSDoc com os tipos adequados em parâmetros, adicione-os!
@matthew-dean, obrigado pelos comentários detalhados! Informá-lo-á sobre as atualizações.