Prettier

Prettier とは

Prettier は、ソースコードを構文木として読み直し、決まった規則で印字し直すコードフォーマッターである。公式ドキュメントは自らを「オピニオネイテッド」と称し、整形結果の細部を利用者に選ばせない立場を明示している。狙いはスタイル論争を止めることで、選べる項目が増えるほど「どのオプションが正しいか」の論争に化けてしまうため、公式は「歴史的経緯で少数のオプションがあるが、これ以上は増やさない」と書いている。

対応するのは JavaScript、JSX、TypeScript、Flow、Vue、Angular、CSS / Less / SCSS、HTML、Ember / Handlebars、JSON、GraphQL、Markdown、YAML など。2026 年 8 月時点の安定版は 3 系 (3.9.6・2026 年 7 月 21 日公開) で、メジャー更新では既定の整形結果そのものが変わる。3.0.0 (2023 年 7 月 5 日) では trailingComma の既定が es5 から all に変わっている。

ESLint vs Prettier

両者は競合しない。役割分担は ESLint 側の方針転換で公式に定まった。ESLint は 2023 年 10 月 26 日の告知で整形系ルール (空白・セミコロン・クォートなど体裁だけを強制するルール) の非推奨を予告し、v8.53.0 で正式に非推奨とした。以降は、体裁を Prettier、バグの芽の検出を ESLint に寄せる構成が標準になっている。

ツール	役割	例
ESLint	コード品質 (バグ検出)	未使用変数、== の使用
Prettier	コードフォーマット (見た目)	インデント、改行、クォート

ESLint: 「この変数は使われていません」 → コードの問題
Prettier: 「セミコロンを付けます」 → 見た目の統一

両方を動かす場合、ESLint 側に残っている整形系ルールが Prettier の出力と衝突することがある。eslint-config-prettier は「Prettier と競合する、または不要になるルールをすべて無効化する」設定として配布されており、ESLint 設定の最後に読み込ませて衝突を消すのが定番。

設定

.prettierrc に書く項目は多くない。実務で触るのはこの程度。

{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "all",
  "printWidth": 100
}

既定値は覚えておくと差分の理由が読める。tabWidth は 2、trailingComma は 3.0.0 以降 all、endOfLine は 2.0.0 以降 lf、printWidth は 80 で、公式は読みやすさの観点から 80 を超える指定を推奨していない。上の例の printWidth: 100 はその既定を上書きしたもの。

選べない部分の方が多い、という点が Prettier の性格である。改行をどこで入れるか、括弧を付けるかどうかは Prettier が決め、利用者に指定させない。整形結果が好みに合わないときの逃げ道は、その範囲を prettier-ignore コメントや .prettierignore で対象外にすることだけになる。この割り切りを受け入れられるかが導入の分かれ目。

Biome との比較

同じ用途で名前が挙がるのが Biome。

観点	Prettier	Biome
実装	JavaScript で書かれ Node.js 上で動く	Rust 実装で高速をうたう
機能	フォーマットのみ	フォーマット + リンター
設定	.prettierrc	biome.json
対応範囲	Vue、Angular、Handlebars、YAML なども扱う	Prettier 互換 97 % と公式が表記

Biome の公式サイトは、対応を JavaScript、TypeScript、JSX、TSX、JSON、HTML、CSS、GraphQL とし、Prettier との互換性を 97 % と記載している (2026 年 8 月時点)。この数値は公式の自己申告で、非互換の一覧も併せて公開されている。判断材料にするなら、対象のリポジトリで両方をかけて差分を見るのが確実。扱うファイルの種類で決まる場面も多く、Vue や Handlebars、YAML が混ざるリポジトリでは Prettier 側に寄る。

pre-commit hook での自動フォーマット

package.json に整形コマンドと lint-staged の対象を書く。hook 本体は husky などで別に登録する必要があり、この設定だけでは commit 時に何も起きない。

{
  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  },
  "lint-staged": {
    "*.{ts,tsx,js,json,md}": "prettier --write"
  }
}

commit 前に書き換えるため、整形漏れが履歴に入らない。ただし対象は staged なファイルだけなので、CI 側の検査も残しておく。

CI での検証

CI では書き換えずに検査だけを行う。--check は整形が必要なファイルが 1 つでもあれば終了コード 1 で終わるため、そのまま失敗として扱える。

- run: npx prettier --check .
# フォーマットされていないファイルがあれば CI が失敗

SAM テンプレートのフォーマット

Prettier は YAML も扱う。SAM テンプレートで使う !Ref や !Sub、!GetAtt といった短縮タグも、3.9.6 で整形した場合はそのまま保持される。

変わるのは引用符で、既定の singleQuote: false に従って '2010-09-09' は "2010-09-09" になる。CloudFormation としての意味は同じだが、既存のテンプレートを初めて通すと引用符だけの差分がテンプレート全体に出る。差分を避けたいなら .prettierignore で除外し、そろえたいなら整形だけのコミットとして分けて入れる。

フォーマッターの導入効果

効果が一番はっきり出るのはレビューで、体裁の指摘が議題から消える。書き手の側でも、改行位置を手で詰める作業がなくなる。差分にも整形の揺れが混ざらなくなるため、読むべき行が実質的な変更だけに絞られる。逆に、導入後に設定を変えると変更が全ファイルに及ぶので、printWidth のような値は最初に決めて動かさない方が差分は静かになる。

導入時に決めておくこと

決めることは 3 つに絞られる。1 つ目は対象で、生成物や外部から取り込んだファイルを .prettierignore で外す。2 つ目は実行位置で、エディタの保存時・commit 前・CI のどこで走らせ、どこまで自動で書き換えるかを決める。3 つ目は既存コードを一括整形する時期。

3 つ目が一番荒れる。全ファイルが動くため、整形だけのコミットを 1 つ作り、その commit の ID を .git-blame-ignore-revs に並べて git blame --ignore-revs-file の対象外にしておくと、行の由来を追うときに整形コミットが表に出てこない。未 merge のブランチが多い時期に一括整形すると衝突が増えるので、区切りの良い時点を選ぶ。