なぜでしょうか?

このプロジェクトは、ESLint とtypescript-eslintチームが、メンテナンスコストのためコアからフォーマット/スタイリング関連のルールを非推奨にすることを決定したときに開始されました。このプロジェクトでは、これらのルールを移植して、別のパッケージとして配布します。これらはコミュニティとして維持していきます。

さらに、隙間を埋め、より優れたスタイリング制御を提供するためにいくつかの新しいルールも作成しました。

リンターとフォーマッタ

リンターとフォーマッタは異なるスコープのツールであることから、ESLint を使用してソースコードをフォーマットすることを思いとどまるような議論がいくつかあるのをご覧になったことがあるかもしれません。ESLint がフォーマットを行うのに最も効率的なツールではないことは一般的に同意していますが、自動修正機能を備えた ESLint が現在でもソースコードフォーマットに最適なツールであると考えています。各ルールをきめ細かく制御し、驚異的な拡張性があり、ソースコードの入力内容を尊重するからです。

Prettier や dprint のような人気のあるフォーマッタは、コードのフォーマットに優れています。ただし、私たちが問題視している主な点は、「読み取りと再印刷」のアプローチによりソースコードからのすべてのスタイル情報を破棄することです。つまり、より「人間が読みやすい」と考えるスタイルを維持することはできません。

以下は、固定 printWidth オプションが原因で Prettier と dprint がコードのラップ/アンラップを強制的に行う 2 つの例です。これによりコードの見やすさが低下するだけでなく、コンテンツの長さを変更したときにバージョン管理で不必要なラップ/アンラップの差分が生じます。

この動作は、そのアプローチの基本的な性質により必須です。

ESLint の文体ルールを使用すると、作者/チームの意図を反映した元のコードスタイルを維持しながら、同様のフォーマットの互換性を実現し、一度に修正を適用できます。

このプロジェクトは、そのような詳細事項を重視し、コードスタイルを完全に制御したい人のためにメンテナンスされています。

詳細に興味がある場合は、アンソニー・フーのなぜ私は Prettier を使用しないのかという投稿を読むことをお勧めします。