Html5-boilerplate: RFC: migración a ESLint

¿Nadie? Me contento con dejar el status quo. ESLint es genial, pero necesitaría estar convencido para hacer el cambio (y luego alguien tendría que _hacer_ el cambio en un PR). Dejaré esto abierto por otra semana y si no hay acción, cerraré.

Puedo hacer relaciones públicas para esto. ESLint es posiblemente una de las herramientas más utilizadas en el ecosistema de JavaScript.

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

@roblarsen Estoy totalmente al lado de @amilajack en esto,
Hice una breve comparación entre los dos con algunos datos que recopilé de la Web, si quieres echar un vistazo.

Gracias chicos. Eso es genial. ¿Alguien más quiere intervenir?

@amilajack gracias por la oferta a PR. Es muy apreciado.

@roblarsen ¡De
@amilajack No dudes en enviarme un mensaje si vienes a necesitar ayuda. :Obrero:

@amilajack ¿

@ryzokuken Hay un PR abierto al que necesito echarle un vistazo y fusionarme. # 1930

Recomiendo buscar en Standard, que es una adición a ESLint y bastante popular. Para ser honesto, es un alivio dejar de mantener las configuraciones de ESLint ...

@ArmorDarks Aunque me gusta el estilo Estándar, no creo que sea bueno obligar a otros a seguirlo. Especialmente los desarrolladores sin mucho conocimiento o experiencia, ya que su código puede dar lugar a errores inesperados en tiempo de ejecución y causar más problemas, incluso llevando a un mayor número de problemas para el proyecto.

Por mucho que me guste la flexibilidad del lenguaje de programación, esa ventaja tiene un precio, y la pregunta es si estamos dispuestos a pagar ese precio. Las reglas más estrictas casi siempre hacen que el código sea más fácil de entender y, como consecuencia, más confiable, incluso a medida que el proyecto crece.

Además, los puntos y comas ganan en popularidad, tomando como ejemplo la guía de estilo JavaScript de Airbnb: uno de los repositorios con más estrellas en GitHub y mayor número de descargas en NPM. [1] [2] [3] [4]

Además, tendríamos que actualizar todos los archivos JavaScript, ya que todos usan punto y coma. [5] [6]

Por lo tanto, no creo que este tema vale la pena el bikeshedding .

Referencias:

[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

De todos modos, todo se reducirá a disputas de estilo de código. Solo estoy proponiendo una alternativa probada en batalla.

Por cierto, debo resaltar que no importa con qué opción irá el boilerplate (ya sea ESLint con las propias reglas del proyecto, ya sea una configuración popular de ESLint, como airbnb, o sea Estándar), _de todos modos impondrá algo a los usuarios a seguir_. Así que es solo una cuestión de qué se hará cumplir exactamente.

En este punto, quiero cambiar a eslint con la menor interrupción posible. Eso incluye eliminar las reglas existentes que tenemos implementadas al por mayor sin al menos una discusión de cuáles deberían ser las nuevas reglas (razón por la cual el PR existente para eslint es DOA).

Moriré en la colina de punto y coma, por ejemplo.

Como nota: los consumidores reales del conjunto de reglas se limitan a los mantenedores y cualquiera que esté creando relaciones públicas a conciencia y probando su código. No enviaremos un eslintrc en el dist. El beneficio real, en términos del proyecto, es que _lo hacemos_ y podemos servir como un ejemplo de cómo debería ser un buen desarrollador web.

Moriré en la colina de punto y coma, por ejemplo.

Eso es solo unos pocos trazos con expresiones regulares, ya sabes. Pero si usarlos o no para algunas personas parece ser un tema doloroso ...

No enviaremos un eslintrc en el dist. El beneficio real, en términos del proyecto, es que lo hacemos y podemos servir como ejemplo de cómo debería ser un buen desarrollador web.

Pero envía el código JS, que se incluirá en otros proyectos, que luego se enlazará, y las personas se verán obligadas a editarlo para que se ajuste a sus reglas, o para usar reglas HTML5Boilerplate. Es por eso que JS debería estar lo más cerca posible de los estándares de la comunidad JS, y creo que es inevitable hacer algunos cambios necesarios en las reglas y el estilo de código. Y no es tan problemático, en realidad: Standard y ESLint con --fix solucionarán automáticamente la mayor parte del error de regla introducido.

El problema real es qué considerar el estándar de la comunidad en JS World.

Buenos puntos. Es bueno recordar los efectos posteriores incluso de la pequeña cantidad de JS que enviamos.

Y para aclarar, no estoy en contra de hacer cambios. Lo que no quiero hacer es hacer cambios al por mayor sin discutirlo (así que gracias por ser parte de la discusión 👍). Si bien estoy bastante desesperado por sacar 6.0 por la puerta ahora mismo, generalmente no tengo prisa por hacer cambios. aquí a menos que sean los cambios correctos.

Una opción es aplicar la configuración eslint:recommended que informa problemas comunes, pero que en realidad no impone preferencias de estilo. En ese caso, ESLint solo serviría para prevenir errores y bugs. Realmente es una especie de configuración mínima de sentido común.

Las únicas reglas relacionadas con el estilo que propondría agregar en ese caso son las que están presentes en su .editorconfig : sin espacios en blanco finales, 4 espacios en blanco y nuevas líneas finales.

4 sangrías espaciales

Solo para la información, ninguno de los estilos de código populares que usan sangrías de 4 espacios ya no.

https://github.com/h5bp/html5-boilerplate/issues/1913#issuecomment -377298563 (eslint: recomendar) suena bien, aunque tengo una preferencia personal por https://github.com/h5bp/html5-boilerplate/ issues / 1913 # issuecomment -318050971 (StandardJS).

En broma: https://github.com/christophwitzko/semicolon-indent#semicolon -indent

También estoy con Standard, porque no solo mantienen una buena configuración con validación a través de la comunidad, sino que también envían excelentes adiciones probadas además de ESLint.

Pero para ser justos, también debería mencionar a Prettier . Sin embargo, mi voto sigue siendo para Standard.

Recordatorio de antes en la discusión

Moriré en la colina de punto y coma, por ejemplo.

Imagina que es un juego que sobrevive, y como si estuviéramos en el año 2005 decidiendo pestañas frente a espacios.

Por cierto, vale la pena mencionar lo de Prettier: debe combinarse con una buena configuración de ESLint, porque casi todo lo que Prettier mantiene es el estilo del código, mientras que las configuraciones de ESLint (y especialmente la de Standard) cubren también muchas buenas o malas prácticas no estilísticas.