はじめに

前提としてフロントエンドの話です。

ソースレビューを運用する中で以下のような課題が見えてきました。

• ソース量が多くなればなるほど、インデント等のフォーマット部分の指摘と修正作業の時間がもったいない
• コーディングルールを書いたのはいいが、ソースの可読性を考慮したルールを入れると量が多くなり、比例して実装コストとレビューコストも多くなる
• 挙句の果てにソースの見た目のレビューに妥協し始め（いけない）、汚いソースが生まれてしまう
• これでは開発者もレビュアーも無駄に負担が増えるばかり

そして。。

最近モダンフロントを学習している中で、当たり前のように「ESLint+Prettier」が導入されていることを知りました。

ESLintとPrettierって何？

ESLint

• ECMAScript/JavaScriptのコードに見られるパターンを特定し、報告するためのツール
• コードの一貫性を高め、バグを回避することを目的としている
• 定めたルールに対して違反していたら警告/エラーを出し、ルールによってはソースをルールに沿って自動修正することができる

Prettier

• コードフォーマッター
• 主にフロントエンドで使用される言語をサポート
  • JavaScript
  • JSX
  • Angular
  • Vue
  • Flow
  • TypeScript
  • CSS, Less, and SCSS
  • HTML
  • JSON
  • GraphQL
  • Markdown
  • YAML

ESLintでJavaScriptの構文を定められたルールで解析、違反していたら警告を出し、Prettierでソースコードのフォーマットを整える。
上記を人がやるのではなく、機械に任せてしまおう。という感じです。

人 vs ESLint+Prettier

では人がチェックする場合と、ESLint+Prettierにチェックさせる場合の差を考え、ESLint+Prettierのメリットを見ていきます。

コーディングルールを理解する

• 人：コーディングルールを知らない人がいたら知ってもらいます。多くの場合そのためにドキュメントを用意します。
• ESLint:ルールを設定ファイルに書きます。多くの場合、推奨されるルールに関してはプラグインを導入することで意識せず適用されます。ルールに関するドキュメントは既に公式で用意されています。

コーディングルールに基づいてレビューをする

• 人：対象のソースすべてに目を通します。ルールを忘れることもあるのでその都度確認します。たまにルール違反を見逃します。
• ESLint:対象のソースにすべてに高速で目を通します。一度設定されたルールは絶対に忘れません。ルール違反を見逃しません。

ルールに違反したソースコードを指摘する

• 人：指摘しづらい人には伝え方を考えます。場合によっては修正方法を考えて伝えます。伝え方が悪いと修正までに複数回のやり取りを要します。
• ESLint:無慈悲の指摘。ルールによっては無慈悲の強制修正。修正方法は公式ドキュメントを見れば理解できます。

ソースコードのフォーマットを整える

• 人：フォーマットを整えるべき箇所をソースを読んで探します。そして手動で整えます。少し時間がかかります。
• Prettier:フォーマットを整えるべき箇所をソースを読んで探します。そして自動で整えます。お時間はいただきません。

ESLint+Prettier素敵やん。

機械に任せると言いつつ、チェックさせるには人がコマンドを実行しなければいけないです。コマンドの実行漏れてたら結局だめなのでは。。。

husky+lint-staged

【朗報】husky+lint-stagedでコミット直前にESLintとPrettierのコマンドを実行できる。

husky

• コミットやプッシュの際に、コミットメッセージのlint、テストの実行、コードのlintなどを実行できる

lint-staged

• gitステージングにあるファイルを対象に特定のコマンドを実行することができる

huskyとlint-stagedを組み合わせることでコミット直前のタイミングでコミットされるファイルを対象にESLintとPrettierのコマンドを実行できるようになります。

• huskyの設定ファイル

#!/bin/sh

. "$(dirname "$0")/_/husky.sh"

# pre-commitのタイミングでlint-stagedコマンドを実行する
docker-compose exec -T nextjs npx lint-staged

• lint-stagedの設定

module.exports = {
  './src/**/*.{js,jsx,ts,tsx}': [
    // eslintの実行 
    (filenames) => `next lint --fix --file ${filenames.map((file) => file.split(process.cwd())[1]).join(' --file ')}`,
    // prettierの実行
    'prettier --write',
  ],
  './src/**/*.{css,scss}': ['stylelint --fix'],
};

これでコミット直前に自動的にESLintとPrettierを走らせることができ、ルール違反の場合はコミットをさせないようにできました。

まとめ

メリットしかないように見えますが、デメリットも当然あります。

• ルールに沿っていないとコミットができないので、開発スピードをある程度犠牲にする必要がある
  • プロジェクトによって採用するルールを柔軟に決めていく必要がある
• 既存のプロジェクトに導入するとなると、適用後のテストに工数がかかる
  • 導入することのメリットとコストを天秤にかけ、コストのほうが大きければ無理に採用するべきではない

逆に言うと新規プロジェクトであればメリットのほうが大きいので、導入する価値はあるかなというのが感想です。

自動化できるものは自動化して快適なフロントエンド開発環境を目指したいですね！