ESLint と Prettier について

2 min read読了の目安(約1900字

他の方のコメント欄で書こうとしたのですが、長くなったので記事にします。

プロジェクトでよく使われている

開発の思想もなにもなく、単によく使われているから、という理由で、ESLint と それと組み合わされて Prettier が使われているプロジェクトをみかけます。ちょい残念です。

調べてみると「今どきPrettierを入れない理由がない」とか書いてあるページも見つかります。やれやれ。

ESLint 最高!

ESLintは様々な設定を切り替えられるので、プロが使うとてもよいツールに思います。ESLint -fix オプションにはとてもお世話になりますし、warn や error などで警告レベルを変えられるのもよく出来ています。

あれだけのオプションで正確な構文解析を行っているので prettier レベルの整形をしようとおもえばできるけれども、そこまでやると変なことも多いからあえてやらない、というプロ向けツールのこだわりをヒシヒシ感じます。

Prettierは...

対して、prettierは整形度合いが派手で目立つものの、変な整形をしてしまうときが多く、設定で個別にON/OFFにできることが少なくて、変な整形部分を解除できないので、かなり使いづらいツールと感じています。

関数名や変数名の単なる数文字の長さの違いによって、ある所は改行されてたり、あるところは改行されなかったりしてしまい、「同じような処理は同じように書かれているべきである。コードの影が一致しておくべき」という書籍リーダブルコードにも書かれている指針にあわせることが無理になってしまいます。

初心者には「めちゃくちゃ自動整形されてすごーい」と見えるのですが、こだわりをもって読みやすいコードを書くプロには使ってほしくないツールだなと思い、この記事書いています。

必須と補助的なもの

また、これは、eslintとprettierだけには限らないことですが、

必須のツールと補佐的なツールでは必須のツールの機能が強化されると補佐的なツールは不要になってしまいます。

eslint -fix の整形機能がより強くなれば prettier は不要となるツール、なので、prettier の設定とか使い方とか覚える気にならないです。

(npm の高速化版として登場している yarn なんかも、npmが高速になれば不要になるので yarnのコマンド体系とかもわざわざ覚えたくないのです npm だけが必須ツールとして存在してくれればいいので。)

prettierはそういう将来的にツールの寿命を考えたときにメリットあるものなのだろうかと思うという理由もあり、自分は使うのをさけています。

連携プラグインについて

また、eslintとprettierだけには限らないことについての、もうひとつです。
(webpack と babel の関係でも同じような問題があります)

eslint - pretter を連携させるプラグインなどは、eslint が単体で verup また、pretter が単体で verup したときに、単体ならどちらも正常に動くのに eslint-prettierのプラグインがどちらかのバージョンアップに追随できなくなって動かなくなってしまいプロジェクト全体で困ったことがおきるので、それゆえに、eslint も prettier もどちらもバージョンがあげられない、という謎の苦しみを生む場合があります。

なので、ツールAと、ツールB、とを接続する、プラグインABというものは、その場限りでは役立つように思いますが、プロジェクトに採用するには将来的なリスクが大きすぎる足かせになるので使用に気をつけなければいけません。

使うとしても ESLint と Prettier は連携して使うんじゃなくて単体で設定をいろいろひねりながら使うのがいいのではないでしょうか。

Prettier を、もし使うなら、バージョンアップ時のトラブルとかの想定もお気をつけください。

私は ESLint だけでシンプルで行きます。そうするとトラブルも再設定も考える必要なく単体でverup 可能で比較的安全です。

そんな感じです。

参照

eslint-plugin-prettier を ESLint から 分離するサンプル – Intellij IDEA の設定変更も | DevelopersIO

https://dev.classmethod.jp/articles/eslint-and-prettier/
あ、やっぱり...去年末の記事ですか、そうですかそうですか。