0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ESLint・Prettier・TypeScriptで「書く前に防ぐ」開発環境を作る

0
Posted at

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はコードを書いた直後に問題を検出できます。

開発を続けるほど、小さな差が積み重なってレビュー効率や品質に大きく影響すると感じています。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?