[JP] よりクリーンで一貫したフロントエンドコードへの次のステップ

ℹ️ This article also has an English version here!

はじめに

第二部では、ESLintとPrettierの設定を最大限に活用する方法を紹介したい。インストールするだけでなく、さらに効果を高めるために追加の調整がいくつかある。

⚠️ もし先にこのページにたどり着いた場合で第一を読みたい方は、こちらをご覧ください。

こんな人におすすめ

• レベルアップしたいジュニア開発者
• フロントエンド開発を見直したいシニア開発者
• 新しいアイデアを探している人

注目すべき点

Prettier

第一部で述べた通り、Prettierはデフォルトで多くの設定が組み込まれているため、インストール以外でやることはあまり多くない。しかし、Prettierを最大限に活用するためのおすすめ設定はいくつかある。

.prettierignore設定

デフォルトでは、Prettierは .gitignore も参照しているが、他にフォーマッタされたくないファイルがあれば追加したほうが良い：

• 本番ビルドに関わる機密ファイル
• CI/CDツールの設定ファイル
• ドキュメント類
• 同一コードベース内の追加ディレクトリ
• キャッシュファイル

フォーマット設定の調整

Prettierにはフォーマット方法を変えるオプションがいくつかある。.prettierrc ファイルでデフォルト値とは異なる設定例は以下の通り：

• "singleAttributePerLine": true
  • HTML・Vue・JSXコンポーネントの属性を1行ずつに分けることで読みやすくする
• "jsxSingleQuote": true
  • JSX内でシングルクオートを使いたい場合
• "quoteProps": "consistent"
  • オブジェクト内で1つでもプロパティにクオートが必要なら、全てのプロパティをクオートする
• "singleQuote": true
  • 上記 jsxSingleQuote と同じ意図
• "trailingComma": "es5"
  • デフォルトの "all" は最低ES2017を必要とし、古いプロジェクトと衝突する可能性がある

フォーマットルールを細かくカスタマイズしたい場合は、Prettierのドキュメント にあるオプション全てを確認すると良い。デフォルト値でも設定ファイルにすべてのオプションを明示的に記載しておくと、共有リポジトリでの不確実性が減り、複数プロジェクトで再利用できるファイルとなる。

プラグイン

Prettierはすでに様々な言語をサポートしているが、サードパーティーのプラグインでフォーマットできる言語がさらに増える。

例えば、フロントエンド開発に人気のTailwind CSSのPrettierのプラグインを導入してみる：

npm install --save-dev --save-exact prettier-plugin-tailwindcss

.prettierrcのpluginsに入れると、PrettierがTailwind CSSのクラス名を推奨される順序に従って並べ替えてくれる

.prettierrc

{
  "plugins": ["prettier-plugin-tailwindcss"]
}

ESLint

以下の説明は、初期化ツールの質問に下記の通り回答したことを前提としているが、基本的な考え方はどの場合も同じである。

✔ What do you want to lint? · javascript
✔ How would you like to use ESLint? · problems
✔ What type of modules does your project use? · esm
✔ Which framework does your project use? · react
✔ Does your project use TypeScript? · Yes
✔ Where does your code run? · browser
✔ Which language do you want your configuration file be written in? · js
The config that you've selected requires the following dependencies:

eslint, @eslint/js, globals, typescript-eslint, eslint-plugin-react
✔ Would you like to install them now? · Yes
✔ Which package manager do you want to use? · npm

設定ファイルについて

初期化ツールは、ルートディレクトリに eslint.config.js ファイルを作成する。このファイルは、ルールを調整したり新しいルールを追加したいときに参照するファイルになる。前述の通り初期化ツールを実行していれば、eslint.config.js は files 配列にある全てのファイルタイプをチェックするように設定されている。また、JavaScript環境向けのESLint推奨ルールに加え、typescript-eslint や eslint-plugin-react の推奨ルールも使用されている。

ルールを調整したい場合は、rules オブジェクトに追加すれば良い。設定ファイル内で後に定義されたルールが優先される。例えば、下記の例では tseslint 推奨の no-unused-vars の "error" 設定を "warn" に変更している：

eslint.config.js

export default defineConfig([
  // ...
  tseslint.configs.recommended,
  pluginReact.configs.flat.recommended,
  {
    rules: {
      "@typescript-eslint/no-unused-vars": "warn",
    },
  },
]);

このようにすれば、既存プロジェクトにルールを追加する際、開発を妨げたくない場合に有用である。この方法であれば、問題のあるコードに警告が出るが、強制的修正しなければならないわけでもない。推奨ルールだけでもプロジェクトを正しい方向に進められるが、さらに強化できるルールもいくつかある。

ルールのおすすめ

下記では、いくつ検討すべきルールのリストと、それぞれの簡単な理由を紹介する：

• "no-console": "error"
  • console.log() を本番に残さないようにする
• "no-constant-condition": ["error", { "checkLoops": "allExceptWhileTrue" }]
  • no-console と同様に、有用なwhile (true)を除いて開発用のコード（例: if (true)）が本番に入らないようにする
• "no-duplicate-imports": "error"
  • import文をより簡潔にする
• "no-nested-ternary": "error"
  • 三項演算子が長くなりすぎて読みにくくなるのを避ける
• "@typescript-eslint/no-explicit-any": "error"
  • 型チェックを無効化するanyの使用を防ぐ
• "@typescript-eslint/strict-boolean-expressions": "error"
  • 真偽値が期待される場所で、nullやundefinedなどのfalsyな値の使用を制限し、明示的な真偽値の使用を強制する
• "@typescript-eslint/switch-exhaustiveness-check": "error"
  • switch 文で、defaultキーワードを使うか、全てのケースを網羅していることを確認する（Rustのコンパイラと match に似ている）
• "@typescript-eslint/consistent-type-imports": "error"
  • 型だけをインポートする場合に便利

💡 上記no-constant-conditionのように、ルールの精度を調整できる追加設定が存在する場合があるので、全てのルールや細かい設定には必ずドキュメントを参照すること。

プラグインについて

初期時に導入したプラグインが足りない場合、設定をさらに拡張するためのサードパーティ製プラグインが多数存在している：

• eslint-plugin-unicorn
  • 様々なルールがあり、モダンなベストプラクティスを強制し、より簡潔なコードの書き方を提案できる
• eslint-plugin-total-functions
  • TypeScriptで「全域関数（total functions）プログラミング」を促進するいくつかのルール
• eslint-plugin-import
  • ES6以降のimport/export構文用
• eslint-plugin-next
  • Next.js開発向けに最適化されたルール

インストールコマンドを実行してから

npm install --save-dev --save-exact eslint-plugin-unicorn

eslint.config.jsに追加することでプラグインを導入できる

eslint.config.js

import eslintPluginUnicorn from 'eslint-plugin-unicorn';

export default defineConfig([
  // ...
  eslintPluginUnicorn.configs.recommended,
]);

カスタムルール

自分のニーズに合わせて独自のルールを作成することも可能である。ESLintには カスタムルール作成に関するドキュメント があるため、ここでは説明しない。しかし、参考としていくつか私のユースケースを紹介する：

• エラーのcatchブロックにログ出力用の関数がない場合に警告を出す
• クライアント側データ（sessionStorage, localStorage）へのgetter/setterの使用を専用ファイルやモジュールに制限する
• 廃止予定の関数やコンポーネントの使用に警告を出す
• React HooksのuseHook命名規則を強制する

自分のプロジェクトで作業していると、コードベース特有の問題が出てくるはずである。同じミスを繰り返しているのに、既存のルールでは指摘できない場合は、当該ミスを検出するカスタムルールを作成すれば解決する。ルール生成にはAIを活用できればさらに効率的である。

おわりに

この記事を通して、ESLintとPrettierについて理解が深まり、どのように活用すればよいかのアイデアが得られたことを願う。この2つのツールは強力な組み合わせで、多くのプロジェクトで利用されており、カスタマイズ性の高さから柔軟かつ長く使えるものである。よりクリーンで一貫したコードを目指そう！