既に Prettier を使ったプロジェクトを運用しており、後から Prettier のルールを変更したくなった場合の手順について説明します。

実際の自分のユースケース

trailingComma をつけた方が、Git の履歴が読みやすくなると思ったので、これを新たに追加します。

module.exports = {
  singleQuote: true,
  semi: false,
  trailingComma: 'all' # 追加
}

既存のソースを一気に直す

prettier のコマンドで既存のファイルを一気に整形していきます。

以下のコマンドで対象ファイルを src と test 配下の、全ての .js もしくは .vue で拡張子が終わるファイルとしました。こうすると、.spec.js 等のテストファイルも対象にできるので便利です。

npx prettier --write "{src,test}/**/{*.vue,*.js}"

コミット時に Prettier が実行されるように修正

公式ドキュメント をみて対応。

正確にはわかっていないのですが、コミットをすると、自動で Prettier が実行されるようです。

yarn add -D lint-staged husky

設定を package.json に書き込みます。

{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,vue}": ["prettier --write", "git add"]
  }
}

確かにコミットをし終えた時に、Prettier で整形されます。

なぜ Prettier が必要か

補足ですが、Prettier がなぜ必要なのでしょうか。公式ドキュメントにガーッと書いてありますが…

私が Prettier を導入する利点として一番大きなものは、コミットした際にどこが変更されたのか明確になる、という点です。

例えば、人によって改行の位置が違ったり、Prettier を使う人と使わない人がいた場合には、単なる開業や、単なる Prettier の実行をするだけでも、Git はソースコードが変更されたと判断しますから、もちろんコミットできる対象になってしまいます。しかし、機能が変わっていないのにコミットされると、コードレビュー時にそのソースを一応読まないといけないので、面倒が増えます。Prettier が常に実行されていれば、そういうことにはなりません。

ということで機械に任せれることは機械にやってもらいましょう。