はじめに
フロントエンド開発では「TypeScript」「tsc」「ESLint」がセットで語られることが多くありますが、それぞれ役割が異なります。本記事ではこの3つの関係を整理します。
TypeScriptとは
TypeScriptは、JavaScriptに静的型付けの機能を追加した言語です。JavaScriptのスーパーセット(上位互換)として設計されており、TypeScriptで書かれたコードは最終的にプレーンなJavaScriptへと変換(コンパイル)されて実行されます。
// JavaScript
function add(a, b) {
return a + b;
}
// TypeScript
function add(a: number, b: number): number {
return a + b;
}
JavaScriptは実行時まで型のミスに気づけない(動的型付け)言語ですが、TypeScriptでは引数や戻り値に型を明記することで、コードを書いている段階(コンパイル前)で型の不整合をエディタやビルドツールが検出してくれます。これにより、「文字列を渡すつもりが数値を渡してしまっていた」といった種類のバグを、実行前に発見しやすくなります。
tsc：TypeScriptコンパイラ
tsc(TypeScript Compiler) は、TypeScriptの公式コンパイラです。TypeScriptのコード(.ts/.tsx)を実際に動作させるためには、最終的にJavaScriptに変換する必要があり、この変換処理を担うのがtscです。
tsc app.ts # app.tsをコンパイルし、app.jsを生成する
tsc --noEmit # コンパイル結果のファイルは出力せず、型チェックだけを行う
--noEmitオプションはよく使われるパターンです。Next.js等のフレームワークでは、実際のビルド処理は別のツールチェインが担当することが多く、tscは「型に誤りがないかをチェックするためだけ」に使われることがあります。CI(継続的インテグレーション)のパイプラインにtsc --noEmitを組み込んでおくと、型エラーが残ったコードのマージを防げます。
ESLint：コードの品質チェックツール
ESLintは、JavaScript/TypeScriptのコードから、潜在的な問題やコーディング規約からの逸脱を検出するリンター(静的解析ツール) です。
tscが主に「型が正しいかどうか」を見るのに対し、ESLintはより広い範囲の問題を検出対象にします。
- 未使用の変数が残っている
-
==と===の使い分けのような、意図しないバグを生みやすい書き方 - チームで定めたコーディングスタイルからの逸脱(インデント、クォートの統一等)
- 特定のライブラリの誤った使い方(Reactのフックのルール違反等)
ESLintは「ルール」の集合体として構成されており、プロジェクトごとに有効化するルールセット(shareable config)を選択・カスタマイズして使います。何もルールを設定していない状態では警告やエラーは出ないため、プロジェクトの目的に合わせてルールを明示的に有効化していく必要があります。
npx eslint . # プロジェクト全体をチェックする
npx eslint . --fix # 自動修正可能な問題を自動で直す
tscとESLintの役割分担
| ツール | 主な役割 | 検出する問題の例 |
|---|---|---|
| tsc | 型チェック・コンパイル | 型の不整合、存在しないプロパティへのアクセス |
| ESLint | コード品質・スタイルチェック | 未使用変数、危険な書き方、コーディング規約違反 |
両者は競合するものではなく、補完し合う関係にあります。実際のプロジェクトでは、次のようにそれぞれの役割で組み合わせて使うのが一般的です。
-
tsc --noEmitで型エラーがないことを確認する -
eslint .でコード品質・スタイル上の問題がないことを確認する - 両方をクリアした状態で、初めてコードをマージ・デプロイする
まとめ
| 用語 | 内容 |
|---|---|
| TypeScript | JavaScriptに静的型付けを追加した言語。最終的にJavaScriptへコンパイルされる |
| tsc | TypeScriptの公式コンパイラ。型チェックとJavaScriptへの変換を担う |
tsc --noEmit |
ファイル出力を伴わず、型チェックのみを行うオプション |
| ESLint | コードの品質・スタイルを静的に解析するリンター |