Html5-boilerplate: RFC：ESLintへの移行

誰でも？ 私は現状を維持することに満足しています。 ESLintは素晴らしいですが、変更を加えることを確信する必要があります（その後、誰かがPRで変更を_行う必要があります）。これをもう1週間開いたままにし、アクションがない場合は閉じます。

私はこれをPRすることができます。 ESLintは、間違いなくjavascriptエコシステムで最も広く使用されているツールの1つです。

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

@roblarsen私は完全に@amilajackの側にいます、
ご覧になりたい場合は、Webから収集したいくつかのデータを使用して2つを簡単に比較しました。

みんなありがとう。 それは素晴らしいことです。 他の誰かがチャイムをしたいですか？

@amilajackPRへの申し出に感謝します。 本当にありがたいです。

@roblarsenどういたしまして！
@amilajack助けが必要になった場合は、

@amilajackまだこれに取り組んでいますか？

@ryzokuken私が見てマージする必要があるオープンPRがあります。＃1930

ESLintに加えて非常に人気のあるStandardを調べることをお勧めします。 正直なところ、ESLint構成の維持を最終的に停止することは使用の安心として...

@ArmorDarks私はスタンダードスタイルが好きですが、他の人にそれに従うように強制するのは良いことではないと思います。 特に、知識や経験があまりない開発者は、コードが予期しないランタイムエラーを引き起こし、さらに問題を引き起こし、プロジェクトの問題の数を増やす可能性があるためです。

プログラミング言語の柔軟性が好きなのと同じくらい、そのような特典には代償が伴います。問題は、その代償を払っても構わないと思っているかどうかです。 より厳格なルールにより、プロジェクトが成長しても、ほとんどの場合、コードが理解しやすくなり、結果として信頼性が高まります。

さらに、AirbnbのJavaScriptスタイルガイドを例にとると、セミコロンが人気を博しています。GitHubで最もスターの高いリポジトリの1つであり、NPMでのダウンロード数が多いです。[1] [2] [3] [4]

また、すべてのJavaScriptファイルはすでにセミコロンを使用しているため、更新する必要があります。[5] [6]

したがって、私はこの主題がバイクシェッドの価値があるとは

参照：

[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

とにかく、それはすべてコードスタイルの論争に要約されます。 私はただ戦いでテストされた代替案を提案しています。

ところで、ボイラープレートがどのオプションになるか（プロジェクト独自のルールを持つESLint、airbnbのような人気のあるESLint構成、または標準）に関係なく、_とにかくユーザーにフォローする何かを強制することを強調する必要があります_。 したがって、それは正確に何が実施されるかという問題です。

この時点で、中断を最小限に抑えてeslintに切り替えたいと思います。 これには、少なくとも新しいルールがどうあるべきかについての議論なしに、私たちが大規模に実施している既存のルールを吹き飛ばすことも含まれます（これが、eslintの既存のPRがDOAである理由です）。

たとえば、セミコロンの丘で死ぬでしょう。

注：ルールセットの実際の利用者は、メンテナと、PRを誠実に作成し、実際にコードをテストしている人に限定されます。 eslintrcをdistに発送しません。 プロジェクトの観点からの本当の利点は、私たちが_それを行う_ことであり、優れたWeb開発者がどのように見えるべきかの例として役立つことができるということです。

たとえば、セミコロンの丘で死ぬでしょう。

これは、正規表現を使用したほんの数ストロークです。 しかし、それらを使用するかどうかは、確かに一部の人々にとってはつらいテーマのようです...

eslintrcを遠方に発送することはありません。 プロジェクトの観点からの本当の利点は、私たちがそれを行い、優れたWeb開発者がどのように見えるべきかの例として役立つことができるということです。

ただし、JSコードを出荷すると、他のプロジェクトに含まれ、後でリントされます。ユーザーは、ルールに合わせてコードを編集するか、HTML5Boilerplateルールを使用するように強制されます。 そのため、JSはJSコミュニティの標準にできるだけ近づける必要があり、ルールやコードスタイルに必要な変更を加えることは避けられないと思います。 実際、それほど問題はありません— --fixを使用したStandardおよびESLintは、導入されたルールエラーの大部分を自動的に修正します。

本当の問題は、JSの世界でコミュニティ標準を何と見なすかです。

良い点。 少量のJSを出荷した場合でも、ダウンストリームの影響を思い出すのは良いことです。

そして明確にするために、私は変更を加えることに反対していません。 私がやりたくないのは、話し合いなしで大規模な変更を加えることです（したがって、話し合いに参加してくれてありがとう👍）今は6.0を公開したいと思っていますが、通常は急いで変更を加える必要はありません。それらが正しい変更でない限り、ここにあります。

1つのオプションは、一般的な問題を報告するeslint:recommendedを適用することですが、実際には文体の設定を課しません。 その場合、ESLintはエラーやバグを防ぐのに役立ちます。 これは、実際には一種の最小限の常識的な構成です。

その場合に追加することを提案する唯一のスタイル関連のルールは、 .editorconfig存在するルールです。末尾に空白がなく、4つのスペースインデントがあり、最後の改行があります。

4つのスペースインデント

参考までに、4つのスペースを使用する一般的なコードスタイルは、もはやインデントされていません。

https://github.com/h5bp/html5-boilerplate/issues/1913#issuecomment -377298563（eslint：recommend）は良さそうですが、私はhttps://github.com/h5bp/html5-boilerplate/を個人的に好み

冗談めかして： https ：

私もStandardを使用しています。なぜなら、コミュニティを通じて検証された優れた構成を維持するだけでなく、ESLintの上に優れたテスト済みの追加機能を出荷しているからです。

しかし、公平を期すために、 Prettierについても言及する必要があります。 しかし、私の投票はまだスタンダードを表しています。

ディスカッションの前半からのリマインダー

たとえば、セミコロンの丘で死ぬでしょう。

それが生き残ったゲームであり、2005年のようにタブとスペースを決定していると想像してみてください。

ところで、Prettierについて言及する価値があります。これは、優れたESLint構成と組み合わせる必要があります。これは、Prettierが維持するほとんどすべてがコードスタイルであるのに対し、ESLint構成（特にStandardの構成）は、多くの非文体の良いまたは悪い慣行もカバーしているためです。