Html5-boilerplate: RFC: Migração para ESLint

Qualquer um? Estou contente em deixar o status quo. ESLint é ótimo, mas eu preciso ser convencido a fazer a mudança (e então alguém teria que _fazer_ a mudança em um PR). Vou deixar isso aberto por mais uma semana e se não houver ação, vou encerrar.

Eu posso fazer relações públicas para isso. ESLint é indiscutivelmente uma das ferramentas mais amplamente utilizadas no ecossistema javascript.

http://www.npmtrends.com/eslint-vs-jshint

@roblarsen estou totalmente do lado de @amilajack nisso,
Eu fiz uma breve comparação entre os dois com alguns dados que reuni na Web, se você quiser dar uma olhada.

Obrigado rapazes. Isso é ótimo. Alguém tem algo a acrescentar?

@amilajack obrigado pela oferta de RP. É muito apreciado.

@roblarsen De nada!
@amilajack Sinta-se à vontade para me enviar uma mensagem se precisar de alguma ajuda. :trabalhador da construção:

@amilajack Você ainda está trabalhando nisso?

@ryzokuken Há um PR aberto que preciso examinar e integrar. # 1930

Eu recomendo olhar para o Standard, que é um acréscimo ao ESLint, e bastante popular. Para ser honesto, é um alívio finalmente parar de manter as configurações ESLint ...

@ArmorDarks Embora eu goste do estilo Standard, não acho que seja bom forçar outros a segui-lo. Especialmente desenvolvedores sem muito conhecimento ou experiência, pois seu código pode levar a erros inesperados de tempo de execução e causar mais problemas, levando até mesmo a um número maior de problemas para o projeto.

Por mais que eu goste da flexibilidade da linguagem de programação, esse benefício tem um preço, e a questão é se estamos dispostos a pagar esse preço. Regras mais rígidas quase sempre tornam o código mais fácil de entender e mais confiável como consequência, mesmo com o crescimento do projeto.

Além disso, os pontos-e-vírgulas ganham por popularidade, tomando o guia de estilo JavaScript do Airbnb como exemplo: um dos repositórios mais marcados no GitHub e números de download mais altos no NPM. [1] [2] [3] [4]

Além disso, precisaríamos atualizar todos os arquivos JavaScript, pois todos já estão usando ponto-e-vírgulas. [5] [6]

Portanto, não creio que esse assunto valha a pena o ciclismo .

Referências:

[1] https://github.com/airbnb/javascript
[2] https://www.npmjs.com/package/eslint-config-airbnb-base
[3] https://www.npmjs.com/package/eslint-config-airbnb
[4] https://www.npmjs.com/package/eslint-config-standard
[5] https://github.com/h5bp/html5-boilerplate/blob/master/gulpfile.babel.js
[6] https://github.com/h5bp/html5-boilerplate/blob/master/src/js/plugins.js

Isso tudo vai se resumir a disputas de estilo de código de qualquer maneira. Estou apenas propondo uma alternativa testada em batalha.

A propósito, devo destacar, que não importa com qual opção o boilerplate irá (seja ESLint com as próprias regras do projeto, seja uma configuração ESLint popular, como airbnb, ou seja Standard), _de qualquer forma, ele impõe algo aos usuários a seguir_. Portanto, é apenas uma questão de o que exatamente será aplicado.

Neste ponto, quero mudar para eslint com o mínimo de interrupção possível. Isso inclui ignorar as regras existentes que temos em vigor no atacado, sem pelo menos uma discussão sobre quais deveriam ser as novas regras (razão pela qual o PR existente para eslint é DOA).

Vou morrer na colina dos pontos e vírgulas, por exemplo.

Como uma observação: os consumidores reais do conjunto de regras são limitados aos mantenedores e qualquer um que esteja criando PRs conscientemente e testando seu código. Não enviaremos eslintrc no dist. O benefício real, em termos de projeto, é que nós _fazemos_ e podemos servir como um exemplo de como deve ser um bom desenvolvedor web.

Vou morrer na colina dos pontos e vírgulas, por exemplo.

São apenas alguns traços com regex, você sabe. Mas usá-los ou não para algumas pessoas realmente parece ser um tema doloroso ...

Não enviaremos um eslintrc no dist. O verdadeiro benefício, em termos de projeto, é que o fazemos e podemos servir de exemplo de como deve ser um bom desenvolvedor web.

Mas você envia o código JS, que será incluído em outros projetos, que mais tarde serão lintados, e as pessoas serão forçadas a editá-lo para se ajustar às suas regras ou a usar as regras do HTML5Boilerplate. É por isso que JS deve estar o mais próximo possível dos padrões da comunidade JS, e eu acho que fazer algumas mudanças necessárias nas regras e no estilo de código é inevitável. E não é tão problemático, realmente - Standard e ESLint com --fix irão corrigir automaticamente a maior parte do erro de regra introduzido.

A verdadeira questão é o que considerar o padrão da comunidade no mundo JS.

Bons pontos. É bom ser lembrado dos efeitos posteriores até mesmo da pequena quantidade de JS que enviamos.

E para esclarecer, não sou contra fazer alterações. O que não quero fazer é fazer alterações em massa sem discussão (então, obrigado por fazer parte da discussão 👍) Embora eu esteja bastante desesperado para lançar o 6.0 agora, geralmente não tenho pressa em fazer alterações aqui, a menos que sejam as mudanças certas.

Uma opção é aplicar a configuração eslint:recommended que relata problemas comuns, mas não impõe preferências estilísticas. Nesse caso, o ESLint serviria apenas para prevenir erros e bugs. É realmente uma configuração mínima de bom senso.

As únicas regras relacionadas a estilo que eu proporia adicionar nesse caso são aquelas presentes em seu .editorconfig : sem espaço em branco à direita, 4 recuos de espaço e novas linhas finais.

4 recuos de espaço

Apenas para informação, nenhum dos estilos de código populares usam mais recuos de 4 espaços.

https://github.com/h5bp/html5-boilerplate/issues/1913#issuecomment -377298563 (eslint: recomendar) parece bom, embora eu tenha uma preferência pessoal por https://github.com/h5bp/html5-boilerplate/ Issues / 1913 # issuecomment -318050971 (StandardJS).

De brincadeira: https://github.com/christophwitzko/semicolon-indent#semicolon -indent

Estou com o Standard também, porque eles não apenas mantêm uma boa configuração com validação pela comunidade, mas também fornecem excelentes adições testadas no ESLint.

Mas, para ser justo, também devo mencionar o Prettier . Porém, meu voto ainda significa Standard.

Lembrete do início da discussão

Vou morrer na colina dos pontos e vírgulas, por exemplo.

Imagine que é um jogo de sobrevivência e, como se estivéssemos no ano de 2005, decidindo entre tabulações e espaços.

Aliás, vale a pena mencionar a coisa sobre o Prettier - ele deve ser combinado com uma boa configuração ESLint, porque quase tudo que o Prettier mantém é o estilo do código, enquanto as configurações ESLint (e especialmente o do Standard) cobrem também muitas práticas não estilísticas, boas ou más.