Html5-boilerplate: RFC: migration vers ESLint

N'importe qui? Je suis content de quitter le statu quo. ESLint est génial, mais je devrais être convaincu pour faire le changement (et alors quelqu'un devrait _make_ le changement dans un PR).

Je peux PR pour ça. ESLint est sans doute l'un des outils les plus largement utilisés dans l'écosystème javascript.

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

@roblarsen Je suis totalement du côté de
J'ai fait une brève comparaison entre les deux avec quelques données que j'ai recueillies sur le Web si vous voulez jeter un coup d'œil.

Merci les gars. C'est super. Quelqu'un d'autre veut intervenir?

@amilajack merci pour l'offre à PR. C'est vraiment apprécié.

@roblarsen De rien !
@amilajack N'hésitez pas à m'envoyer un message si vous avez besoin d'aide. :ouvrier du batiment:

@amilajack Travaillez -vous toujours là-dessus?

@ryzokuken Il y a un PR ouvert que je dois regarder et fusionner. # 1930

Je recommanderais de se pencher sur Standard, qui est un ajout au-dessus d'ESLint, et qui est assez populaire. Pour être honnête, c'est comme un soulagement à l'usage d'arrêter enfin de maintenir les configs ESLint ...

@ArmorDarks Même si j'aime le style Standard, je ne pense pas qu'il soit bon d'imposer aux autres de le suivre. Surtout les développeurs sans beaucoup de connaissances ou d'expérience, car leur code peut entraîner des erreurs d'exécution inattendues et provoquer d'autres problèmes, voire augmenter le nombre de problèmes pour le projet.

Même si j'aime la flexibilité du langage de programmation, un tel avantage a un prix, et la question est de savoir si nous sommes prêts à payer ce prix. Des règles plus strictes rendent presque toujours le code plus facile à comprendre et plus fiable en conséquence, même à mesure que le projet se développe.

De plus, les points-virgules gagnent en popularité, en prenant comme exemple le guide de style JavaScript d'Airbnb: l'un des référentiels les plus étoilés sur GitHub et des numéros de téléchargement plus élevés sur NPM. [1] [2] [3] [4]

De plus, nous aurions besoin de mettre à jour tous les fichiers JavaScript, car ils utilisent déjà tous des points-virgules. [5] [6]

Par conséquent, je ne crois pas que ce sujet vaille la peine de faire du vélo .

Références:

[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

Tout cela se résumera de toute façon à des conflits de style de code. Je propose juste une alternative testée au combat.

Btw, je dois souligner que quelle que soit l'option utilisée par passe-partout (que ce soit ESLint avec les propres règles du projet, que ce soit la configuration ESLint populaire, comme airbnb, ou que ce soit Standard), _il imposera de toute façon quelque chose aux utilisateurs à suivre_. Il s'agit donc simplement de savoir exactement ce qui sera appliqué.

À ce stade, je souhaite passer à eslint avec le moins d'interruption possible. Cela inclut de faire sauter les règles existantes que nous avons en place sans au moins une discussion sur ce que les nouvelles règles devraient être (c'est pourquoi le PR existant pour eslint est DOA).

Je mourrai sur la colline des points-virgules, par exemple.

À noter: les utilisateurs réels du jeu de règles sont limités aux responsables et à toute personne qui crée consciencieusement des PR et teste réellement leur code. Nous n'expédierons pas de eslintrc dans la distribution. Le véritable avantage, en termes de projet, est que nous le faisons et que nous pouvons servir d'exemple de ce à quoi un bon développeur Web devrait ressembler.

Je mourrai sur la colline des points-virgules, par exemple.

C'est juste quelques coups avec regex, vous savez. Mais que les utiliser ou non pour certaines personnes semble en effet être un thème douloureux ...

Nous n'expédierons pas d'eslintrc dans le dist. Le véritable avantage, en termes de projet, est que nous le faisons et que nous pouvons servir d'exemple de ce à quoi un bon développeur Web devrait ressembler.

Mais vous expédiez le code JS, qui sera inclus dans d'autres projets, qui seront plus tard lintés, et les gens seront obligés de le modifier pour l'adapter à leurs règles, ou d'utiliser les règles HTML5Boilerplate. C'est pourquoi JS devrait être aussi proche que possible des standards de la communauté JS, et je pense qu'il est inévitable d'apporter les modifications nécessaires aux règles et au style de code. Et pas si problématique, vraiment - Standard et ESLint avec --fix corrigeront automatiquement la plupart des erreurs de règle introduites.

Le vrai problème est de savoir ce qu'il faut considérer comme un standard communautaire dans le monde JS.

Bons points. Il est bon de se rappeler les effets en aval même de la petite quantité de JS que nous expédions.

Et pour clarifier, je ne suis pas contre les changements. Ce que je ne veux pas faire, c'est apporter des changements globaux sans discussion (donc merci de faire partie de la discussion 👍) Bien que je sois plutôt désespéré de sortir la 6.0 maintenant, je ne suis généralement pas pressé d'apporter des changements ici à moins qu'ils ne soient les bons changements.

Une option consiste à appliquer la configuration eslint:recommended qui signale les problèmes courants, mais n'impose pas vraiment de préférences stylistiques. Dans ce cas, ESLint servirait simplement à éviter les erreurs et les bogues. C'est vraiment une sorte de configuration minimale et de bon sens.

Les seules règles liées au style que je proposerais d'ajouter dans ce cas sont celles présentes dans votre .editorconfig : pas d'espaces de fin, 4 retraits d'espaces et dernières nouvelles lignes.

4 espaces indentés

Juste pour information, aucun des styles de code populaires utilisant des retraits de 4 espaces n'est plus.

https://github.com/h5bp/html5-boilerplate/issues/1913#issuecomment -377298563 (eslint: recommend) sonne bien, même si j'ai une préférence personnelle pour https://github.com/h5bp/html5-boilerplate/ issues / 1913 # issueecomment -318050971 (StandardJS).

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

Je suis aussi avec Standard, car ils maintiennent non seulement une bonne configuration avec une validation par la communauté, mais ils expédient également d'excellents ajouts testés en plus de l'ESLint.

Mais pour être juste, je devrais également mentionner Prettier . Cependant, mon vote vaut toujours pour Standard.

Rappel du début de la discussion

Je mourrai sur la colline des points-virgules, par exemple.

Imaginez que c'est un jeu qui survit, et comme si nous étions en 2005 en décidant des onglets et des espaces.

Btw, il convient de mentionner la chose à propos de Prettier - il devrait être associé à une bonne configuration ESLint, car la plupart du temps tout ce que Prettier maintient est le style de code, tandis que les configurations ESLint (et en particulier celle de Standard) couvrant également beaucoup de bonnes ou mauvaises pratiques non stylistiques.