Prettierを使わない理由

この記事はPrettierを使用している人を非難したり、脱Prettierを推奨する事を目的としていません。
こういった考え方もあるということをひとつの意見としてご覧いただければ幸いです。

勘違いしている人が多そうなので追記します。
Prettierを使わないというのは私が独断で決めた事ではないです。
チームが発足する際の技術選定で合意は取れていますし、私が関与していない別のチームでも同様にPrettier無しで開発しています。
私達のチームはメンバー同士を互いに信頼していますし、細いスタイルで喧嘩を始めるようなメンバーは居ないので安心してください。

はじめに

Prettierはコードフォーマッターとして広く使われているツールです。
コードスタイルに関する議論をなくすことを目的としており、ESLintとは異なりデフォルト設定のままですぐに使えるのが特徴です。
さらに、PrettierはJS以外にもHTMLやCSS、Markdownなどのフォーマットにも対応しています。
そして、ESLintでは自動修正が難しい部分(max-len等)もPrettierを使えば自動で修正できるため、ESLintよりも優れた点が多くあります。

そんなPrettierの利点を紹介しましたが、正直なところ私はPrettierをあまり好きではありません。
この記事では、私がPrettierを使わない理由を説明したいと思います。

printWidthが強すぎる

Prettierはデフォルトで80文字で折り返しを行います。
これはコードを読みやすくするための設定ですが、読みやすさのためにあえて改行していない所も強制的に改行されます。(逆も然り)
// prettier-ignoreとコメントする事で、Prettierのフォーマットを無効に出来ますが、ignoreするかどうかは実装者次第です。
実装者によってはignoreして読みやすく書く人もいれば、ignoreしないでPrettierに任せてしまう人もいるかもしれません。
これでは、Prettierの利点であるコードスタイルの一貫性が失われてしまいます。

配列定義

将来的に要素が増える可能性がある配列を定義する場合、下記のようにPRのDiffが見やすくなるように改行しておくことがあります。

const arr = [
  elment1,
  elelment2,
  elment3,
+ element4,
];

しかし、Prettierを通すと下記のように置き換えられてしまいます。

const arr = [elment1, elelment2, elment3];

関数呼び出し

関数呼び出しの引数が多い場合、可読性の為に下記のように改行しておくことがあります。

func(
  arg1,
  arg2,
  arg3,
);

しかし、こちらも関数定義と同様にPrettierを通すと下記のように置き換えられてしまいます。

func(arg1, arg2, arg3);

メソッドチェーン

メソッドチェーンを行う場合、下記のように改行しておくことがあります。

const test1 = func()
  .chainMethod()
  .chainMethod()
  .chainMethod()
  .chainMethod();

const test2 = func()
  .chainMethod()
  .chainMethod()
  .chainMethod()
  .chainMethod()
  .chainMethod();

const test3 = func()
  .chainMethod()
  .chainMethod()
  .chainMethod();

しかし、Prettierを通すと下記のように置き換えられてしまいます。

const test1 = func().chainMethod().chainMethod().chainMethod().chainMethod();

const test2 = func()
  .chainMethod()
  .chainMethod()
  .chainMethod()
  .chainMethod()
  .chainMethod();

const test3 = func().chainMethod().chainMethod().chainMethod();

改行されるかどうかは、PrettierのprintWidthに依存し、読みやすさの為の改行は全て無視されます。
読みやすさを優先したいのであれば、下記のように// prettier-ignoreを付けるしかありません。

// prettier-ignore
const test1 = func()
  .chainMethod()
  .chainMethod()
  .chainMethod()
  .chainMethod();

// prettier-ignore
const test2 = func()
  .chainMethod()
  .chainMethod()
  .chainMethod()
  .chainMethod()
  .chainMethod();

// prettier-ignore
const test3 = func()
  .chainMethod()
  .chainMethod()
  .chainMethod();

ESLintと被る部分が多い

Prettierを使う場合、ESLintと併用して使う方は多いと思います。
ESLintはLinterとFormatterの両方の機能を備えている為、Prettierと併用する場合には幾つかのルールが重複してしまいます。
そのため、eslint-config-prettierを使ってESLintのフォーマット関連のルールを無効にすることが推奨されています。

以下は、eslint-config-prettierが実際に無効にするルールの一覧です。
これだけ多くのルールを無効にするのであれば、ESLintのみを使用してコードフォーマットを行う方がよりシンプルではないでしょうか。
https://github.com/prettier/eslint-config-prettier/blob/main/index.js

また、ESLintにはデフォルトの設定はありませんが、recommendedという推奨されるルールのプリセットが用意されています。
コードスタイルに関する議論をなくすことを目的とするならば、ESLintのrecommendedを使用するだけで十分ではないでしょうか。
ESLintのPluginの選定ですら面倒なのであれば、eslint-config-airbnbや@antfu/eslint-configのようなプリセットを使うこともできます。

実際に、私が所属するチームではESLintのみを使用していますが、コードスタイルに関する議論はほとんど発生していません。
ESLintと競合するルールを無効化する必要があるという複雑さが増えることが、私がPrettierを使用しない理由の一つです。

まとめ

Prettierには、全員に同じコードスタイルを強制できるという利点がありますが、場合によっては好ましくないスタイルも強制されることがあります。
ESLintだけでもコードのフォーマットは十分可能ですし、今のところPrettierを使用していれば良かった等と困ったこともありません。

Prettierに限らず、ツールを導入する際はメリットとデメリットをしっかり理解し、自分たちのチームに最適なツールを選択することが重要だと思います。

Prettierについて多くの不満を述べてきましたが、PrettierはJS/TSだけでなく、HTML、CSS、Markdownなどのフォーマットにも対応しており、これらのフォーマットについては非常に便利です。
@antfu/eslint-configでは、JS/TS以外のフォーマットについてPrettierを使用するよう設定されています。