PrettierとESlint(あるいはTSLint)を共存させていい感じに使う。

2019/06/28(追記): 色々後ろのほう書いてますが、TypeScriptはeslint-typescript使いましょう

フォーマッタも全部ESLintにお任せしていたのだが、
フォーマッタはPrettier一択だよ系の話を聞くようになったので導入してみた。
その時にPrettier関連のパッケージがごちゃごちゃして混乱したので、以下に整理しておく。

考え方

2つのツールの機能はそれぞれ

• Prettier・・・フォーマッタ
• ESLint・・・静的解析ツール + フォーマッタ

となっている。
なので、共存時の基本的な考え方は、

• Prettier・・・フォーマッタ
• ESLint・・・静的解析ツール

という切り分け。
Prettierのみがフォーマットのルールを決め、ESLintはエラーを出すだけという感じ。

ただ、これを実現する方法は以下の2通りある。

方針①:Prettierでフォーマット、ESLintで静的解析

まんまである。完全にやることを分ける。
ESLintは解析してエラーを出すだけで、prettier --writeでフォーマットをかける。

そのためにやることはESLintのフォーマット機能を無効化すること。
これはeslint-config-prettierを導入することで実現できる。

以下がESLintのシンプルな設定例。

# .eslintrc.yml

parser: babel-eslint　# flowに必要
parserOptions:
  sourceType: module
plugins:
  - flowtype
  - react
extends:
  - eslint:recommended
  - plugin:flowtype/recommended
  - plugin:react/recommended
  - prettier
  - prettier/flowtype
  - prettier/react

extendsでeslint-config-prettierを設定する。
上のケースはReactとFlowを導入している例なので、prettier/flowtypeとprettier/reactを指定して追加で関連ルールを無効化している。

フォーマットは一切Prettierに任せることになるので、ルールを変更したい場合は.prettierrcを用意する必要がある。
シンプル派なので諸々表示しない方向性で修正した例。

# .prettierrc.yml

trailingComma: none # 最後の,省略
singleQuote: true # 'xxx'
semi: false # ;省略

この方針の場合、VS Codeで利用する場合はESLintとPrettierの拡張機能を導入すればそのままいい感じに動いた。
Web Stormでの設定はこちらを参考にFile Watcherに設定することで保存時にフォーマットが可能。

方針②:Prettierルールを突っ込んで全部ESLintで全部やる

Prettierは使わずに、代わりにPrettierのルールをESLintに突っ込んだのち、
eslint --fixでフォーマットもしてしまうという方針。
このケースの場合では全部ESLintで行うため、Prettierのインストールは必要ない。

これを実現するためには

1. ESLintのフォーマットルールを無効にする(eslint-config-prettier)
2. ESLintにPrettierのフォーマットルールを追加する(eslint-plugin-prettier)
   の2つが必要になる。

①の例と同じ設定した場合の.eslintrcはこんな感じ。

# .eslintrc.yml

parser: babel-eslint # flowに必要
parserOptions:
  sourceType: module
plugins:
  - flowtype
  - react
  - prettier
extends:
  - eslint:recommended
  - plugin:flowtype/recommended
  - plugin:react/recommended
  - plugin:prettier/recommended
  - prettier
  - prettier/flowtype
  - prettier/react
rules:
  prettier/prettier:
    - error
    - trailingComma: none # 最後の,省略
      singleQuote: true # 'xxx'
      semi: false # ;省略

pluginsでeslint-plugin-prettierを設定し、extendsでeslint-config-prettierを設定する。
Prettierのルールを変更したい場合にはrulesの所に設定する。

この方針でやる場合、
VS CodeではESLintとPrettierの拡張を入れたのち、"eslint.enable": trueの設定が必要。
Web Stormの場合はこちらを参考に。
ただ、自分の環境でWeb Stormの設定した際には保存後フォーマットされるまでにタイムラグがあって違和感があったので導入をあきらめた。

どっちがいいの

好きなほうでやればいいと思うが、
PrettierとESLintで明確に役割を切り分けるという考えにマッチしているという意味で
①のほうが頭を整理しやすい気はする。
②のほうが設定ファイルが1つにまとめられてよいという人もいるかもしれない。
個人としては、もともとは②のやり方で導入を開始したが、Web Stormと相性がわるいようなので、現在は①に落ち着いている。

2018/08/04　追記

会社のコードをTypeScriptに移行したのを機にeslintからtslintに移行した。
設定はeslintでもtslintでも特に変わらないのだが、
移行してみてprettierの領域ではないが、自動修正したいようなルールが結構有ることに気づいた。

わかりやすい例でいうと、tslintでtslint:recommendedを設定したときに適用される
ordered-imports(importするものの順序をABC順にする。)みたいなルールだ。
これらのルールはprettierで処理することはできないがtslint --fixすれば自動修正されるので②のやり方をすれば自動修正される。
①のやり方でもエディタのプラグインの機能などで簡単に修正できるのだが、こうしたeslint/tslint側に自動修正できるルールがあることも考えると、特に理由がなければ②のやり方を導入したほうが良いかなぁというのが今の結論。