ESLint / Prettier 導入ガイド: Husky, CI/CD 統合, コード品質の可視化まで徹底解説

2024/02/12に公開

はじめに

開発チームでコードの品質を統一するために、Linter(ESLint)と Formatter(Prettier)は欠かせません。Linter はコードの構文やスタイルの問題を検出し、Formatter はコードの整形を統一します。本記事では、以下の取り組みについて詳しく解説します。

  • 開発チームのコーディングスタイルに合わせたESLintルールを策定し、プロジェクトに最適な設定
  • コードフォーマットを自動で統一するため、Prettierを導入
  • Git フックを活用し、コミット前に自動でESLintやPrettierを実行
  • コードスタイルの問題を自動で解決
  • 設定方法や使用方法のドキュメントを作成
  • Huskyを使ってコミットメッセージのフォーマットを統一
  • CI/CDパイプラインにLintとPrettierを統合
  • コード品質をレポートとして可視化し、チーム全体で品質改善の進捗を確認できる仕組みを作成

ESLint と Prettier の導入方法や設定、Git Hooks を活用した自動適用まで、具体的な手順を紹介します。

Linter / Formatter の導入が重要な理由

ソフトウェア開発では、コードの一貫性や品質を保つことが重要です。特にチーム開発では、個々の開発者ごとにコードスタイルが異なると、レビューやメンテナンスが困難になります。

Linter(コードの静的解析ツール)や Formatter(コードの整形ツール)を導入することで、以下のメリットがあります。

  • コードの統一性を維持 し、可読性を向上させる
  • コーディング規約の遵守を強制 することで品質を担保
  • エラーやバグの早期発見 を可能にする
  • コードレビューの負担を軽減 し、より本質的な議論に集中できる

ESLint の導入とプロジェクトに最適な設定

ESLintは、JavaScriptおよびTypeScriptのコードを静的解析し、コードの品質や一貫性を向上させるためのリンター(Linter)です。

ESLintの特徴

  • コードの品質向上: 構文エラーやバグの可能性を事前に検出
  • コーディングスタイルの統一: チームで統一されたスタイルを適用
  • カスタマイズ可能: 独自のルールを設定可能
  • プラグイン対応: React、TypeScript、Prettier などの拡張が可能
  • 自動修正機能: 一部の問題は eslint --fix で自動修正できる

具体的なルール例

ESLintでは、多くのルールがあり、例えば以下のようなものがあります。

ルール名 説明
no-unused-vars 未使用の変数を禁止
no-undef 未定義の変数を使用禁止
prefer-const 変更しない変数は const を使用
eqeqeq == ではなく === を使用
semi セミコロンを強制
quotes シングルクォート or ダブルクォートを統一
arrow-body-style 不要な {} を省略
object-curly-spacing オブジェクトの {} 内にスペースを入れる
react/jsx-uses-react JSX 使用時に React を import
react/prop-types PropTypes の使用を強制(TSなら無効)
no-console console.log を禁止
curly 制御構造の {} を必須
no-multiple-empty-lines 空行の最大数を制限

ESLint のインストール

まず、プロジェクトに ESLint を導入します。

npm install --save-dev eslint

または Yarn を使用する場合:

yarn add -D eslint

初期設定

ESLint の設定を初期化するには、以下のコマンドを実行します。

npx eslint --init

対話形式で以下の項目を選択します。

  • どのような用途で使用しますか? → To check syntax and find problems
  • どの JavaScript 実行環境を使用しますか? → Browser または Node.js
  • どの JavaScript フレームワークを使用していますか? → React など必要なものを選択
  • どの設定スタイルを使用しますか? → JSON または JavaScript

設定完了後、プロジェクトに .eslintrc.json または .eslintrc.js が作成されます。

ルールのカスタマイズ

開発チームのコーディングスタイルに合わせて .eslintrc.js を編集します。

module.exports = {
  env: {
    browser: true,
    es2021: true,
  },
  extends: ["eslint:recommended", "plugin:react/recommended"],
  parserOptions: {
    ecmaVersion: 12,
    sourceType: "module",
  },
  rules: {
    "indent": ["error", 2],
    "quotes": ["error", "single"],
    "semi": ["error", "always"],
  },
};
  • extends: 推奨ルールセットを適用
  • rules: 独自ルールを追加
  • plugins: ReactやTypeScriptのサポートを追加

段階的にルールを増やしていくことが長くESLintを使うコツかと思います。

Prettier の導入と設定

Prettier は、JavaScript や TypeScript などのコードを自動的に整形してくれるコードフォーマッターです。

特徴

  • コードのスタイルを統一: チーム内でコードの書き方を統一できる。
  • 自動整形: インデントやスペースの使い方を自動で調整。
  • 手動調整不要: ルールに従って一貫したフォーマットを適用するので、開発者が細かくスタイルを気にする必要がない。
  • エディタとの統合: VS Code などのエディタで保存時に自動フォーマットが可能。
  • ESLintとの併用可能: コードのスタイルだけでなく、静的解析(コードのバグチェック)と組み合わせて使える。

対応言語

  • JavaScript, TypeScript
  • HTML, CSS, SCSS, Less
  • JSON, YAML, Markdown
  • GraphQL, SQL など

Prettier のインストール

Prettier を導入するには、以下のコマンドを実行します。

npm install --save-dev prettier

または Yarn を使用する場合:

yarn add -D prettier

設定ファイルの作成

プロジェクトルートに .prettierrc を作成し、フォーマットルールを定義します。

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

各プロパティの詳細

  1. printWidth: 100

    • 説明: 1行の最大文字数を指定する。
    • 効果: 1行が 100文字を超えると自動で改行 される。コードが横に長くなりすぎるのを防ぐ。
    • デフォルト値: 80
  2. tabWidth: 2

    • 説明: インデントのスペースの幅を指定する。
    • 効果:インデントに 2スペース を使用。4スペースより コードがコンパクトになり、視認性が向上 する。
    • デフォルト値: 2
  3. semi: true

    • 説明: 文の末尾に ;(セミコロン)を付けるかどうかを指定する。
    • 効果: true → 必ずセミコロンを付ける。false → セミコロンを 省略 する
    • デフォルト値: true
    • 補足:JavaScript ではセミコロンを省略できるが、コードの意図しない解釈を防ぐため、つけるのが推奨されることが多い。
  4. singleQuote: true

    • 説明: 文字列を '(シングルクォート)で囲むか、"(ダブルクォート)で囲むかを指定する。
    • 効果:true → シングルクォート ' を使用。false → ダブルクォート " を使用
    • デフォルト値: false(ダブルクォート)
    • 補足
      • JavaScript のデフォルトの JSON フォーマットは ダブルクォート なので、JSON ファイルを扱う場合はダブルクォートの方が一般的。
      • ただし、JavaScript や TypeScript ではシングルクォートの方がタイピングが楽なので、シングルクォートを好む人が多い。

ESLint と Prettier の競合回避

ESLint は JavaScript/TypeScript のコード品質を向上させるための静的解析ツールで、コードの構文ミスやベストプラクティスに反する記述を指摘します。
Prettier はコードのフォーマットを統一するためのツールで、スタイルのばらつきを防ぎます。

この2つを併用すると、ESLint の一部のルール(例: インデントやクォートのスタイル)と Prettier の自動フォーマットが競合することがあります。この問題を解決するために、以下の方法で ESLint に Prettier を統合します。

npm install --save-dev eslint-config-prettier eslint-plugin-prettier

パッケージの役割

  • eslint-config-prettier

    • ESLint のフォーマットに関するルール(例: indent, quotes)を無効化し、Prettier に一任するための設定。
    • これにより、ESLint が Prettier のルールと競合しなくなる。
  • eslint-plugin-prettier

    • ESLint 内で Prettier を実行し、コードフォーマットの違反を ESLint のエラーとして報告するプラグイン。

.eslintrc.js を編集して、Prettier を ESLint に統合します。

module.exports = {
  extends: ["eslint:recommended", "plugin:react/recommended", "prettier"],
  plugins: ["prettier"],
  rules: {
    "prettier/prettier": "error"
  }
};

設定のポイント

  • "extends" に "prettier" を追加することで、ESLint のフォーマット関連のルールを無効化し、Prettier に処理を任せる。
  • "plugins" に "prettier" を追加し、Prettier のフォーマットを ESLint のルールとしてチェックできるようにする。
  • "rules" に "prettier/prettier": "error" を追加することで、Prettier のフォーマット違反を ESLint のエラーとして検出し、修正を促す。

Git Hooks を活用して自動適用

Git Hooks は、特定の Git 操作(例: commit, push, merge)の前後に自動で実行されるスクリプトです。
これを利用して、コミット前に ESLint と Prettier を適用し、コード品質を確保できます。

Husky と lint-staged の導入

Git Hooks を簡単に管理するために、以下のツールを導入します。

  • Husky

    • Git フックを管理するツールで、コミットやプッシュのタイミングで自動的にスクリプトを実行できます。これにより、コード品質の向上やコミットルールの統一 などが実現できます。
    • pre-commit や pre-push などのフックを簡単に適用可能
    • pre-push:プッシュ前に実行
  • lint-staged

    • コミットされる(= ステージングされた)ファイルに対してのみ ESLintPrettier を適用できるツール
    • プロジェクト全体ではなく、変更のあったファイルだけに ESLint / Prettier を適用することで、実行時間を短縮

Husky と lint-staged のインストール

コミット前に ESLintPrettier を自動適用するために huskylint-staged を導入します。

npm install --save-dev husky lint-staged

package.json に以下のスクリプトを追加します。

"husky": {
  "hooks": {
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
  "*.{js,jsx,ts,tsx}": [
    "eslint --fix",
    "prettier --write"
  ]
}

設定の詳細

  • Husky の設定

    • "pre-commit": "lint-staged"
      • コミット前(pre-commit)に lint-staged を実行
      • これにより、コミットされるファイルだけが対象になる
  • lint-staged の設定

    • "*.{js,jsx,ts,tsx}": JavaScript, JSX, TypeScript, TSX ファイルを対象にする
    • ["eslint --fix", "prettier --write"]:
      • eslint --fix で ESLint のルール違反を自動修正
      • prettier --write で Prettier を適用してフォーマットを整える

Huskyの有効化

Husky の設定を適用するために、以下のコマンドを実行します。

npx husky install

または、Yarn を使う場合:

yarn husky install

このコマンドを実行すると、.husky ディレクトリが作成され、Git Hooks のスクリプトが管理されるようになります。

コードスタイルの問題を自動修正

手動で ESLint と Prettier を適用

すべてのファイルに対して ESLint を適用するには、以下のコマンドを実行します。

npx eslint . --fix

Prettier を適用するには、以下を実行します。

npx prettier --write .

npm scripts に追加

package.json にスクリプトを追加すると、簡単に実行できます。

"scripts": {
  "lint": "eslint . --fix",
  "format": "prettier --write ."
}

Husky を使ったコミットメッセージのフォーマット統一

Husky を利用すると、Git のフックを活用して コミット前やプッシュ前に特定のスクリプトを実行 できます。特にコミットメッセージのフォーマットを統一するために commitlint を組み合わせて使うのが一般的です。

Commitlint のインストールと設定

npm install --save-dev @commitlint/{config-conventional,cli}

これにより、以下のパッケージがインストールされます:

  • @commitlint/config-conventional:一般的なコミットメッセージのルールを定義
  • @commitlint/cli:コミットメッセージをチェックする CLI ツール

commitlint.config.js にルールを設定します。

module.exports = {
  extends: ['@commitlint/config-conventional']
};

例えば、以下のようなコミットメッセージが許可されます:

feat: 新しい機能を追加
fix: バグ修正
docs: ドキュメントを修正
style: コードのフォーマット修正(機能の変更なし)

Husky に commitlint を設定

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

このコマンドを実行すると、.husky/commit-msg というファイルが作成され、そこに commitlint のチェックを実行するスクリプトが追加されます。

動作の仕組み

  • commit-msg フックが実行される
  • npx --no-install commitlint --edit "$1" でコミットメッセージのチェックが行われる
  • ルールに違反している場合はエラーになり、コミットができない

コミットメッセージのカスタマイズ

デフォルトの @commitlint/config-conventional では以下のフォーマットを推奨します。

<type>: <メッセージ>

主な type の種類:

  • feat(新機能)
  • fix(バグ修正)
  • docs(ドキュメント変更)
  • style(フォーマット変更、コードの意味には影響なし)
  • refactor(コードリファクタリング、機能の変更なし)
  • test(テスト追加・修正)
  • chore(ビルドやツール関連の変更)

必要に応じて、カスタマイズできます。

例として、コミットメッセージの 最大文字数 を制限する場合:

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'header-max-length': [2, 'always', 72]
  }
};

CI/CD パイプラインに Lint と Prettier を統合

Lint(ESLint)とコードフォーマット(Prettier)を CI/CD パイプラインで実行することで、以下のメリットがあります。

  • コード品質の向上

    • Lint により、コードの一貫性やエラーを検出しやすくなる。
    • Prettier により、コードフォーマットが統一され、可読性が向上する。
  • 開発者の手間を軽減

    • 手動で Lint を実行する必要がなくなる。
    • プルリクエスト(PR)時に自動でチェックされるため、レビュワーの負担が軽減される。
  • 継続的インテグレーション(CI)に組み込むことで、品質を維持

    • PR に対して Lint やフォーマットチェックが通っていない場合、マージを防ぐことでコードベースの健全性を保てる。

GitHub Actions で ESLint と Prettier を実行

GitHub Actions を使って Lint チェックとフォーマットチェックを自動化する方法を詳しく解説します。

.github/workflows/lint.yml を作成し、以下の設定を追加します。

name: Lint and Format Check
on: [push, pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - run: npm install
      - run: npm run lint
      - run: npm run format:check

このワークフローを機能させるには、package.json に適切なスクリプトを定義する必要があります。

{
  "scripts": {
    "lint": "eslint . --ext .js,.jsx,.ts,.tsx",
    "format": "prettier --write \"src/**/*.{js,jsx,ts,tsx,json,md}\"",
    "format:check": "prettier --check \"src/**/*.{js,jsx,ts,tsx,json,md}\""
  },
  "devDependencies": {
    "eslint": "^8.0.0",
    "prettier": "^3.0.0"
  }
}
  • lint → ESLint をプロジェクト全体に適用
  • format → Prettier でコードのフォーマットを適用
  • format:check → コードフォーマットのチェックを実行(修正はしない)

動作の仕組み

  1. GitHub にコードをプッシュまたは PR を作成
    on: [push, pull_request] により、GitHub にコードがプッシュされるか、PR が作成されると自動でワークフローが実行。

  2. Ubuntu 環境でジョブを実行
    runs-on: ubuntu-latest により、Ubuntu 環境で動作。

  3. リポジトリのコードを取得
    actions/checkout@v3 を使用して、CI 環境にコードをチェックアウト。

  4. Node.js 環境のセットアップ
    actions/setup-node@v3 で Node.js 18 をインストール。

  5. 依存関係のインストール
    npm install で package.json に基づいて必要なパッケージをインストール。

  6. Lint チェックの実行
    npm run lint により、ESLint を実行。

  7. Prettier のフォーマットチェック
    npm run format:check でコードフォーマットが適切かどうかを検証。

おまけ

Lint やフォーマットエラーを自動修正し、それを PR に反映させるには、GitHub Actions で prettier --write を実行してコミットするワークフローを追加できます。

name: Lint and Format Auto Fix

on:
  pull_request:

jobs:
  lint-fix:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - uses: actions/setup-node@v3
        with:
          node-version: 18

      - run: npm install
      - run: npm run lint --fix
      - run: npm run format

      - name: 変更をコミットしてプッシュ
        run: |
          git config --global user.name "github-actions[bot]"
          git config --global user.email "github-actions[bot]@users.noreply.github.com"
          git add .
          git commit -m "chore: apply auto lint and format fixes" || echo "No changes to commit"
          git push
  • ESLint と Prettier を実行し、コードを自動修正。
  • 修正後のコードを GitHub Actions の bot ユーザーとして PR にコミット。
  • git commit -m の後に || echo "No changes to commit" を入れることで、変更がない場合にエラーにならないようにする。

コード品質を可視化する仕組み

Lint レポートの生成

ESLint はコードの静的解析ツールで、JavaScript/TypeScript のコード品質を向上させるために使用されます。eslint-formatter-html を利用すると、ESLint の結果をHTML形式で出力し、ブラウザで視覚的に確認できるようになります。

パッケージのインストール

npm install --save-dev eslint-formatter-html

Lint レポートの生成

npm run lint -- --format html > lint-report.html

Image from Gyazo

参照元:

https://github.com/mazipan/eslint-formatter-html-extended

  • npm run lint はプロジェクトの ESLint 設定に基づいてコードをチェックします。
  • --format html によって、HTML 形式で出力します。
  • > lint-report.html で、出力結果を lint-report.html ファイルに保存します。

活用方法

  • CI/CD パイプラインに組み込んで、Lint エラーの可視化を行う。
  • コードレビュー時にレポートを共有し、修正の指標とする。
  • ローカルでチェックし、ブラウザ上で詳細なエラー内容を確認する。

SonarQube を活用した品質管理

SonarQube は、コードの品質を分析し、バグ・セキュリティ脆弱性・コードの重複・コードの保守性 などを評価するツールです。

https://www.sonarsource.com/jp/products/sonarqube/

SonarQube の導入

docker run -d --name sonar -p 9000:9000 sonarqube
  • docker run -d : バックグラウンドでコンテナを実行。
  • --name sonar : sonar という名前のコンテナを作成。
  • -p 9000:9000 : ローカルの 9000 ポートと SonarQube の 9000 ポートをマッピング。
  • sonarqube : SonarQube の公式 Docker イメージを使用。

プロジェクトの分析

sonar-scanner -Dsonar.projectKey=my_project -Dsonar.sources=src -Dsonar.host.url=http://localhost:9000
  • sonar-scanner : SonarQube にコードを解析させるコマンド。
  • -Dsonar.projectKey=my_project : プロジェクトのキーを指定(SonarQube の管理画面で設定)。
  • -Dsonar.sources=src : src ディレクトリ内のコードを解析対象とする。
  • -Dsonar.host.url=http://localhost:9000 : SonarQube のホスト URL を指定。

活用方法

  • CI/CD に組み込む: コードの品質を継続的に監視し、問題が発生した場合にアラートを出す。
  • 技術的負債の可視化: コードのリファクタリングが必要な箇所を特定する。
  • チーム開発の品質向上: 静的解析による品質向上のための指標として活用する。

まとめ

本記事では、以下の取り組みについて詳しく解説しました。

  • 開発チームのコーディングスタイルに合わせたESLintルールを策定し、プロジェクトに最適な設定
  • コードフォーマットを自動で統一するため、Prettierを導入
  • Git フックを活用し、コミット前に自動でESLintやPrettierを実行
  • コードスタイルの問題を自動で解決
  • 設定方法や使用方法のドキュメントを作成
  • Huskyを使ってコミットメッセージのフォーマットを統一
  • CI/CDパイプラインにLintとPrettierを統合
  • コード品質をレポートとして可視化し、チーム全体で品質改善の進捗を確認できる仕組みを作成

これにより、開発チーム内でのコードスタイルの統一が容易になり、コードレビューの負担を軽減できます。

導入を検討している方は、ぜひ試してみてください!

記事に関するお問い合わせ📝

記事の内容に関するご質問、ご意見などは、下記よりお気軽にお問い合わせください。
ご質問フォームへ

技術支援などお仕事に関するお問い合わせ📄

技術支援やお仕事のご依頼に関するお問い合わせは、下記よりお気軽にお問い合わせください。
お問い合わせフォームへ

関連する技術ブログ