PrettierとLinterを共存させるときの公式オススメが変わったらしいという話
個人でやっているプロジェクトにPrettierとESLintを入れようとしたときの話。
ESLintにもコーディングスタイルを整えるための機能があるので、何も考えずにそのまま両方を入れると、お互いのルールが競合してしまうという問題が発生します。
これを防ぐために、Prettierの公式ドキュメントに共存させるためのオススメ手順が書いているのですが、最近この内容に少し変化があったっぽいということに偶然気がついたので記事にしておきます。
これが公式のドキュメント。書いてあることを雑に要約すると
- コードフォーマットのことはPrettierを、コード品質に関することはLintを使ってくれ
- ただLintツールのルールと競合することがあるからeslint-config-prettierのようなコンフィグを入れてくれ
と書いています。つまり、Linter側のコードフォーマットに関するルールを全て無効化して、その上でPrettierを使ってコードフォーマットをするというのが推奨されています。
(こちらの記事が大変わかりやすく参考になりました)
ここまでの話は昔から同じようなことが書いていたのですが、このあとの部分がここ最近変わったみたいです。
この記事を書いている時点のドキュメントを引用すると以下のような注意書きがあります。
When searching for both Prettier and your linter on the Internet you’ll probably find more related projects. These are generally not recommended, but can be useful in certain circumstances.
First, we have plugins that let you run Prettier as if it was a linter rule:
・eslint-plugin-prettier
・tslint-plugin-prettier
・stylelint-prettier
These plugins were especially useful when Prettier was new. By running Prettier inside your linters, you didn’t have to set up any new infrastructure and you could re-use your editor integrations for the linters. But these days you can run prettier --check . and most editors have Prettier support.
これまた雑に要約すると、
- PrettierをLinterルールのように実行するツール(eslint-plugin-prettierなど)があるが、これはPrettierがまだ新しいツールだった時には役に立っていたが、現在はオススメしない。
- なぜなら、現在は
prettier --check .(dry run的なやつ)があったり、多くのエディターがPrettierをサポートしているからである
また、これらのツールを使うデメリットとして以下が挙げられています。
- Linterとして実行すると、スタイルに関するエラーがエディター上で赤線で表示されたりする。Prettierはコーディングスタイルを忘れるためにあるのに。
- 普通に実行するより遅い
- 1レイヤー増えるので壊れるリスクが増える
こちらのアーカイブを見てもわかるように、過去には公式でeslint-plugin-prettierのようなプラグインをオススメしていたみたいですが、公式オススメではなくなったっぽいという話でした。
ちなみに、LintかけたあとにPrettierをかける手段としてはprettier-eslintというのがリコメンドされていました。ちなみに、prettier-eslintはCLI機能を有していないので、CLIから実行したい人はprettier-eslint-cliというパッケージがまた別で用意されているのでそっちを使うといいかもです。
