こんにちわ、hisayukiです。
Webアプリケーション開発を行っていると、使ったことがある方が多いと思いますESLintとPrettier。
恥ずかしいことに、僕自身この２つの切り分けがちゃんと出来ていなかったです。
今回はこの2つの本来の役割と切り分けをまとめたので書いていきたいと思います。
ESLintとPrettierとは？
ESLint
JavaScriptやTypeScriptのための静的コード分析ツールです。
単純な構文エラーやコーディング規約を定義することができ、コードの一貫性を保つことが出来ます。
設定できるルール一覧がこちら
見ていただくとわかりますが、ここに書いてあるルールだけで200以上とかなり細かく設定することが出来ます。
加えてプラグイン200以上も存在するため、すべて手で設定するようなことはオススメしません。
よく使われる定義の一覧を一括有効する設定があるので、その設定をしたあとに気に入らないのだけoffにすればよいかなと思います。
ちなみに一部のルールに関しては違反している部分をコマンドに--fixを付けることで自動修正することもできます。
Prettier
こちらはコードフォーマッターです。
使う目的としてはESLintと同様に、コーディング規約を定義することでコードの一貫性を保つことが出来ます。
ESLintに比べてルール数は少なく、全部で20弱くらいですね。
ルールの一覧はこちら
対応しているファイル形式はJavaScriptやTypescriptに限らないです。
ESLintとPrettierの違い
非常に混在しやすい理由はあるのですが、役割が全く違います。
ESLintの役割はコードの構文チェックであり、Prettierの役割はコードの整形になります。
どちらも使う目的としてはコードの品質保持のためではあるのですが、明確な境界があることをPrettierの公式は書いています。
Prettier公式はPrettierが注力すべきところはコード1行長さが規定内か、スペースにしなければいけないところをタブになってないか、シングルクォートに統一したいのにダブルクォートになっていないかかなどあくまで決められたコーディングルールに反している部分を検出して整形まですることです。
そのため静的チェックでバグを検出したりする役割はPrettierのやることではないので、Linterを使ってくれとハッキリ書いてます。
なので、役割がはっきりと別れているからESLintとPrettierの両方が入っていることは至って普通のことです。
ただ意外とこの2つを分けて使ってなかったり、ESLintの設定ファイルしかないのにコードが整形されてたりしませんか？
このあたり境界を飛び越えて混在してしまっている理由を個人的な解釈でまとめました。
混在してしまう理由
ESLintがコードフォーマットも出来てしまうため
これが非常にやっかいな感じですね。
僕もちゃんと調べてなかった頃はPrettierのPluginがESLintに入ってるし、ESLintのルールでも整形は出来てたので気にしてなかったんですよね。
ただ、結果的には別にPrettierを動かしていたわけではなく、全てESLintのルールのみでフォーマットしていたことに後から気付きました。
便利と思うかもですが、困ったことにESLintはフォーマッターではないのでPrettierでフォーマット出来ること全てが出来るわけではないです。
検知までは網羅しているのですが、フォーマットに関しては全てが出来るわけではないのでESLintのみにするというのも難しいところだったりします。
例えばスペースとタブが混在していないかのチェック、no-mixed-spaces-and-tabsは検知まではしてくれますが、--fixでどちらかに統一するようなフォーマットは行われません。
機能モリモリでPlugin大量にあるせいか、中途半端になってしまった感はあります。
Prettierが以前はESLintから動かすことを推奨していたため
これは仕方ないかなとは思いました。
Prettierが出た当初は対応しているエディタが少なかったんです。
そのため、当時は対応しているエディタが多いESLintにPluginとして動かしてもらうことにしたようです。
Prettierの実行に必要なものをPluginの中に押し込めば実行はESLintがしてくれるため、ユーザー側への負担を減らそうと考えたみたいです。
そうすることで、まず使ってもらって知名度を上げていった感じですね。
現状はほとんどのエディタがネイティブでPrettierを対応しているため、マーケティングとしては成功したと思います。
ただ、この経緯があっての現状なのかなというのも思います。
ESLintのPluginとして広まったため、Prettierってそもそも何をしてくれてるんだっけ？というのがわかりにくくなってしまっていると思います。
Prettierがエディタからも実行できてしまうため
対応しているエディタが増えてきたのはいいのですが、これによりPrettierがエディタの機能により実行されている場合があります。
VSCodeだと設定次第で、保存タイミング時に自動で実行されますね。
そうするとどこから実行されたのかが分かりにくくなることもあります。
まとめ
ここまでをまとめると、ESLintはLinter（静的解析ツール）であってPrettierはコードフォーマッターです。
ESLintの機能がもりもりなため、フォーマットも一応出来てしまっています。
しかし検知は出来てもフォーマットが出来ないものもあるため、結局はESLintのみすることもルール次第では難しいです。
Prettierも初期時代のことがあるため、Prettierそのものがどう役に立っているのかがわかりにくくなっている側面もあると思います。
今回は過去の経緯から現状こうなっているところまでを書きました。
現状のままだと問題点が多数あるので、対応策とあるべき姿、最後に公式の推奨を次回書きたいと思います。
コメント