ESLint & Prettier入門：TypeScript & Node.jsプロジェクトに導入する手順まとめ

今回は、静的解析ツールのESLintとコードフォーマッターのPrettierをNode.js & TypeScriptプロジェクトに導入する手順を整理していきたいと思います。実際の現場でも使っているケースがかなり多いですが、私自身何となくで使っていたため、正しい理解をできていませんでした。そのため、今回は整理しながら各パッケージの役割や各ルールについての理解を深めていければと思っています。

【得られること】
  ESLintやPrettierの使い方と適用するルールについて理解できる
  Node.js & TypeScriptに対してのプロジェクトに導入することができる

ESLintについて

ESLintとは

ESLintは、JavaScriptやTypeScriptのコード品質やスタイルを自動的にチェックし、一貫性を保つための静的解析ツールです。コードの静的解析を行い、構文エラーや潜在的なバグを検出し、プロジェクト固有のコーディングスタイルに従った指針を強制します。特に、チーム開発時には、コード品質の統一性を維持し、エラーやバグを事前に捉えるため、開発プロセスを改善することが可能。

あわせて読みたい

Find and fix problems in your JavaScript code - ESLint - Pluggable JavaScript Linter A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.

ESLintの特徴

1. 静的解析とリントルール：ESLintはコードを解析し、カスタマイズ可能なリントルールを適用してエラーや潜在的な問題を検出する。これにより、コード品質が向上し、バグを事前に発見可能。
2. カスタマイズ性：プロジェクトに合わせてリントルールを設定可能。開発チームが独自のコーディングガイドラインに従うことができ、一貫性が保たれる。
3. 自動修正：ESLintは一部の問題を自動的に修正可能。コードのフォーマットやスタイルを自動的に統一することで、コードレビューの手間を軽減する。エディターと結合させることにより、さらに効率化可能。
4. 豊富なプラグイン：ESLintは多くのプラグインと拡張機能をサポートしており、異なるプロジェクトやフレームワークに適用可能。これにより、様々なコーディング要件に対応できる。
5. 開発効率向上：コードの品質を向上させ、バグを事前に検出することで、開発効率が向上する。一貫性のあるコーディングスタイルはコラボレーションを容易にし、保守性を高める。

Prettierについて

Prettierとは

Prettierは、コードのフォーマットやスタイルを自動的に整えるコードフォーマッターツールです。開発者がコードのスタイルガイドに従う手間を省き、一貫性のあるコードを生成する。設定が簡単で、JavaScriptやTypeScriptをはじめとする多くのプログラミング言語に対応している。Prettierはコードのインデント、セミコロンの挿入、改行の扱いなどを統一し、コードの可読性を向上させてくれます。多くのエディタやIDEと統合でき、コードを保存時に自動的に整形が可能。プロジェクト全体で一貫性のあるコーディングスタイルを維持し、コードレビューの手間を減らすのに役立ちます。

あわせて読みたい

Prettier · Opinionated Code Formatter Opinionated Code Formatter

Prettierの特徴

1. 自動コードフォーマット：Prettierはコードの自動フォーマットを提供し、コーディングスタイルを自動的に整える。手動でのフォーマット作業を不要にし、一貫性のあるコードを維持する。
2. 簡単なカスタマイズ：カスタム設定を提供し、プロジェクトの要件に合わせてコーディングスタイルを調整できる。設定ファイルを作成し、プロジェクト全体で一貫性を保つ。
3. 連携と効率化：エディタと連携し、保存時に自動フォーマットを実行可能。これにより、コードレビューの手間が減少し、開発プロセスがスムーズとなる。

ESLintとPrettierの違いとそれぞれの役割

ESLintはコード品質とルール遵守に焦点を当て、Prettierはコードの整形と一貫性の向上に焦点を当てている点が違い。一般的に、両方を組み合わせて使用することで、コードの品質とスタイルの両方を管理することができるため、併用することが多い。

導入の流れ

開発環境

• node：v18.15.0
• npm：v9.5.0
• typescript：v5.0.2
• eslint：v8.48.0
• prettier：v3.0.3
• OS：MacOS Monterey

導入手順

実行環境の構築

まずはNode.js + TypeScriptで実行できる環境を構築。
構築方法は以下をベースに実施しましたので、まだ構築できていない方は参考にしてください。

あわせて読みたい

【npm編】Node.js & TypeScriptの実行環境構築手順まとめ 今回はNode.js + TypeScriptにおける実行環境をnpmを用いて構築する手順を備忘録としてまとめていきます。本格的に実装していくための準備として、必要最低限のファイル…

ESLint編：必要なパッケージのインストール

$ npm install -D eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

• eslint: コード品質と規約のチェックを行う静的解析ツール
• @typescript-eslint/parser: TypeScriptコードのESLint解析を可能にするパーサー
• @typescript-eslint/eslint-plugin: TypeScript向けESLintルールを提供するプラグイン

ESLint編：設定ファイルの作成とルールの定義

.eslintrc.jsの作成

module.exports = {
  root: true,
  parser: '@typescript-eslint/parser',
  plugins: ['@typescript-eslint'],
  env: {
    browser: true,
    commonjs: true,
  },
  parserOptions: {
    ecmaVersion: 'latest',
    sourceType: 'module',
    project: './tsconfig.eslint.json',
    tsconfigRootDir: __dirname,
  },
  ignorePatterns: ['dist'],
  extends: [
    'plugin:@typescript-eslint/recommended',
    'plugin:@typescript-eslint/recommended-requiring-type-checking',
  ],
  rules: {
    eqeqeq: 'error', //===にしないとエラー
    'no-console': 'warn', //console.xxxを使うと警告
    'no-warning-comments': [
      //対象のコメントを書くと警告
      'warn',
      { terms: ['todo', 'fixme', 'memo'], location: 'anywhere' },
    ],
    'max-statements': ['warn', 30], //宣言した関数や変数の上限値
    'max-lines': ['warn', 500], //1ファイルの最大行数
    'max-lines-per-function': ['warn', { max: 30, skipBlankLines: true }], //関数内の行数が30行超えると警告
    'max-depth': ['warn', 3], //ネストが3を超えると警告
    complexity: ['warn', 5], //複雑度が5を超えると警告
    '@typescript-eslint/quotes': ['error', 'single'], 
    '@typescript-eslint/naming-convention': [
      'warn',
      { selector: 'variableLike', format: ['camelCase'] },
      { selector: 'method', format: ['camelCase'] },
      { selector: 'typeLike', format: ['PascalCase'] },
      { selector: 'parameter', format: ['camelCase'] },
    ],
    '@typescript-eslint/no-explicit-any': ['error'],
    '@typescript-eslint/no-unused-vars': ['error'],
    '@typescript-eslint/no-require-imports': ['error'],
  },
};

  各プロパティの説明はこちら → リンク

今回は実際に現場で利用しているルールも含めて定義してみましたが、ここで利用しているルールは一部です。
詳しくは公式ドキュメントを参考にチームやプロジェクトに併せてカスタマイズしてください。
  https://eslint.org/docs/latest/rules/

tsconfig.eslint.jsonの作成

.eslintrc.jsファイル自体にもESLintの対象に含めるため、tsconfig.jsonを継承する形でtsconfig.eslint.jsonファイルを作成します。

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "allowJs": true
  },
  "include": ["src", ".*.js", "*.js"]
}

参考：サバイバルTypeScript：TypeScript ESLintの設定ファイルを作る

Prettier編：必要なパッケージのインストール

$ npm install -D prettier eslint-config-prettier

eslint-config-prettierは ESLint のコードフォーマットに関連するルールを無効化し、バグを検出するルールのみを有効にするプラグイン

Prettier編：設定ファイルの作成とルールの定義

.prettierrc.jsの作成

ルート直下に.prettierrc.js ファイルを作成する。

今回は.eslintrc.jsに併せてJSファイルで作成したが、ファイル名に関しては、.prettierrcや.prettierrc.jsonでも問題ない。
  https://prettier.io/docs/en/configuration

ルールの定義

module.exports = {
  tabWidth: 2,
  printWidth: 100,
  useTabs: false,
  semi: true,
  singleQuote: true,
  trailingComma: 'all',
  bracketSpacing: true,
  arrowParens: 'always',
};

あえて記載しているルールもあるが、基本的にはデフォルトで十分である。あとはプロジェクトやチームの慣習に併せてルールを設定する。

  各ルールの詳しい説明はこちら → リンク

.eslintrc.jsに追加

eslint-config-prettierを適用させるために以下の行を追加

module.exports = {
  root: true,
  ...
  extends: [
    'plugin:@typescript-eslint/recommended',
    'plugin:@typescript-eslint/recommended-requiring-type-checking',
    'prettier', //------------ 追加
  ],
  rules: {...},
};

VSCodeの拡張機能追加

正直これらの拡張機能を使わないとあまり恩恵を受けれないため必ず導入する。

ESLint

あわせて読みたい

ESLint - Visual Studio Marketplace Extension for Visual Studio Code - Integrates ESLint JavaScript into VS Code.

Prettier

あわせて読みたい

Prettier - Code formatter - Visual Studio Marketplace Extension for Visual Studio Code - Code formatter using prettier

settings.json

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.codeActionsOnSave": ["source.fixAll.eslint"],
  "editor.formatOnSave": true,
}

プロジェクトのみに上記ルールを適用したい場合は、ルート直下に.vscode/settings.jsonを作成し、上記ルールを記載する。そうすると、VSCode全体で定義しているルールを上書きしてくれる。

設定ファイルと各ルールの説明

ESLint

プロパティ

ルールの書き方

rules: {
  eqeqeq: 'error', // or 2
  'no-console': 'warn', // or 1
  'no-warning-comments': 'off' // or 0
}

ルールの無効化

参考：https://eslint.org/docs/latest/use/configure/rules#disabling-inline-comments

■ ファイル全体への適用

/* eslint max-lines: 0, no-console: 0 */
console.log('ログ出力：1行目') //警告が無効化
...
...
console.log('ログ出力：1000行目') //500行超えていても警告が無効化

■ 一定範囲への適用

const test = () => {
  /* eslint-disable */
  if ('条件1') {
    if ('条件2') {
      if ('条件3') {
        if ('条件4') {
          return true
        } else {
          return false
        }
      }
    }
  }
  /* eslint-enable */
};

※ complexityやmax-depthを無効化する例

■ 対象行のみの適用

記載方法は2パターン

• 無効対象行の前の行
• 無効対象行と同じ行

// eslint-disable-next-line
const anyObject: any = { title: 'text' };

const unused = 1; // eslint-disable-line no-unused-vars

Prettier

ルール

現時点でのルールを記載しているので、情報が古くなっている場合があります。適宜公式ドキュメントを確認してください。
公式：https://prettier.io/docs/en/options.html

ルールの無効化

// prettier-ignoreとコメント追加すると、次行に対しては無効化が可能

//  prettier-ignore

まとめ

今回は、静的解析ツールのESLintとコードフォーマッターのPrettierをNode.js & TypeScriptプロジェクトに導入する手順をまとめてみました。改めて各プロパティやルールがどのような役割をしているのか理解することができました。
これらのツールが導入されていないと、不要なPRレビューが発生したり、フォーマッターの自動修正により余計な差分が発生するケースも多々あります。そのために、チームやプロジェクト間でルールを決めて開発効率をさらに良くする動きが取れるといいですね。
ここまでご覧いただきありがとうございました。