ReactやTypeScriptで開発していると、
- コーディングスタイルが人によって違う
- 型エラーに実行時まで気付けない
- レビューで毎回同じ指摘が入る
ということがあります。
そこで導入したのが、
- ESLint
- Prettier
- TypeScript(tsc)
です。
どれも開発では定番のツールですが、役割は少しずつ異なります。
この記事では、それぞれの役割や導入方法、実際に使って感じたことを紹介します。
それぞれの役割
| ツール | 役割 |
|---|---|
| ESLint | バグになりそうなコードやルール違反を検出 |
| Prettier | コードフォーマットを統一 |
| TypeScript(tsc) | 型エラーを検出 |
似ているようで、それぞれ見ているポイントは異なります。
ESLint
ESLintは静的解析ツールです。
例えば、
const value = 10
if (value == "10") {
console.log("same")
}
ESLintでは
-
==ではなく===を使う - セミコロン
- 未使用変数
- import順
などをチェックできます。
実行すると
npm run lint
警告やエラーとして表示されます。
自動修正
多くのルールは自動修正できます。
npm run lint -- --fix
細かい修正を手作業でする必要がなくなります。
Prettier
Prettierはフォーマッターです。
役割は非常にシンプルで、
コードを自動できれいに整形する
ことです。
例えば
修正前
function hello(name:string){return"Hello "+name}
実行後
function hello(name: string) {
return "Hello " + name;
}
インデントや改行などを統一してくれます。
なぜESLintとPrettierを両方使うの?
役割が違うためです。
ESLint
このコードは危ない
Prettier
このコードは読みやすく整える
という違いがあります。
最近ではESLintは品質チェック、Prettierはフォーマット専用という使い分けが一般的です。
TypeScript(tsc)
TypeScriptコンパイラは、
型が正しいか
をチェックします。
例えば
function add(a: number, b: number) {
return a + b;
}
add("1", 2);
実行すると
Argument of type 'string' is not assignable to parameter of type 'number'.
というエラーになります。
実際にアプリを起動する前に問題を見つけられます。
tscはビルドだけではない
多くのプロジェクトでは
npx tsc --noEmit
を実行しています。
--noEmitを付けることで、
- JavaScriptは生成しない
- 型チェックだけ実施
できます。
CIでもよく使われる方法です。
GitHub Actionsに組み込む
Pull Request時に実行する例です。
- name: Type Check
run: npm run typecheck
- name: ESLint
run: npm run lint
- name: Prettier
run: npm run format:check
問題があればCIが失敗します。
package.json例
{
"scripts": {
"lint": "eslint .",
"lint:fix": "eslint . --fix",
"format": "prettier . --write",
"format:check": "prettier . --check",
"typecheck": "tsc --noEmit"
}
}
ローカルでもCIでも同じコマンドを利用できます。
導入して感じたこと
一番変わったのはレビューの内容でした。
以前は
- インデント
- セミコロン
- import順
- ダブルクォート
といった細かい指摘が多くありました。
導入後は自動で解決できるようになり、
レビューでは
- 設計
- 実装方針
- 命名
- パフォーマンス
など、本来確認したい部分に時間を使えるようになりました。
また、TypeScriptの型チェックがあることで、実行前に不具合へ気付ける場面も増えました。
AIとの相性も良い
最近はAIでコードを書く機会が増えています。
便利な一方で、
- import漏れ
- 型の間違い
- 未使用変数
- フォーマット崩れ
が混ざることもあります。
ESLint・Prettier・TypeScriptをCIに組み込んでおけば、AIが生成したコードも一定の品質でチェックできます。
まとめ
3つのツールは役割が重複しているようで、それぞれ違います。
| ツール | 防げること |
|---|---|
| ESLint | 実装ミス・ルール違反 |
| Prettier | フォーマットのばらつき |
| TypeScript | 型エラー |
テストは実行して初めて分かることを検証します。
一方で、ESLint・Prettier・TypeScriptはコードを書いた直後に問題を検出できます。
開発を続けるほど、小さな差が積み重なってレビュー効率や品質に大きく影響すると感じています。