メインコンテンツへスキップ

よくある質問

ESLintコアのルールを使用していますが、TypeScriptコードで正しく動作しません​

これは、TypeScriptがESLintが認識していない新しい機能を追加するためです。

最初のステップは、こちらの「拡張」ルールのリストを確認することです。「拡張」ルールとは、TypeScript構文をサポートするために基本ESLintルールを拡張するルールです。それがリストにある場合は、試してみて動作するかどうかを確認してください。基本ルールを無効にし、拡張ルールを有効にすることで設定できます。以下は、`semi`ルールの例です。

{
  "rules": {
    "semi": "off",
    "@typescript-eslint/semi": "error"
  }
}

既存の拡張ルールが見つからない場合、または拡張ルールがご自身のケースで機能しない場合は、問題点をご確認ください。コントリビュートガイドには、問題点を報告する最適な方法が記載されています。

毎週新しいバージョンのツールをリリースしています。問題点を報告する**前**に、最新の「拡張」ルールのリストを確認してください。

「多くのファイルがデフォルトプロジェクトで実行されると、パフォーマンスの問題が発生し、リントが遅くなることが知られています」というエラーが表示されます​

これらのエラーは、EXPERIMENTAL_useProjectService のallowDefaultProjectForFilesを非常に広いglobで使用することによって発生します。allowDefaultProjectForFilesは、含まれる各「プロジェクト外」ファイルに対して新しいTypeScript「プログラム」が構築されるため、ファイルごとにパフォーマンスオーバーヘッドが発生します。

このエラーを解決するには、allowDefaultProjectForFilesで使用されるglobを狭めて、含まれるファイルを減らしてください。例:

eslint.config.js
parserOptions: {
  EXPERIMENTAL_useProjectService: {
    allowDefaultProjectForFiles: [
-      "**/*.js",
+      "./*.js"
    ]
  }
}

また、tsconfig.jsonにさらに多くのファイルを含める必要がある場合があります。例:

tsconfig.json
"include": [
  "src",
+ "*.js"
]

これができない場合は、typescript-eslintのtypescript-estreeパッケージに問題点を報告してください。ユースケースとその理由を説明し、ユースケースを理解するために使用できる最小限の再現例を含めてください！

「ESLintは…を実行するように設定されました。ただし、そのTSConfigには/それらのTSConfigのいずれにもこのファイルが含まれていません」というエラーが表示されます​

これらのエラーは、ESLintの設定で、TypeScript設定に含まれていないファイルの型情報の生成を要求していることが原因です。

エラーの修正​

  • ファイルをlintしたくない場合
  • ファイルをlintしたい場合

    • 型対応リントでファイルをlintしたくない場合

      eslint.config.js
      import tseslint from 'typescript-eslint';

      export default tseslint.config(
        // ... the rest of your config ...
        {
          files: ['**/*.js'],
          extends: [tseslint.configs.disableTypeChecked],
        },
      );
      • あるいは、ファイルを個別に型チェックを無効にするには、除外したいファイルのオーバーライドに`parserOptions: { project: false }`を設定します。

    • 型対応リントでファイルをlintしたい場合

      • parserOptions.projectに指定する各TSConfigの`include`オプションを確認してください。すべてのファイルが`include` globに一致する必要があります。そうでない場合、ツールはファイルを見つけることができません。
        • ファイルが`.cjs`、`.js`、または`.mjs`ファイルの場合は、`allowJs`が有効になっていることを確認してください。
      • ファイルが既存のtsconfigの一部ではない場合（たとえば、リポジトリローカルのスクリプト/ツールである場合）、プロジェクトルートに新しいtsconfig（`tsconfig.eslint.json`という名前を付けることをお勧めします）を作成し、その`include`にこのファイルを含めます。これの例として、このリポジトリで以前使用していた設定を確認できます。

詳細​

このエラーは、次の2つの組み合わせによって発生する可能性があります。

  • ソースファイルのESLint設定で、`parserOptions.project`に少なくとも1つのTSConfigファイルが指定されている。
  • それらのTSConfigファイルのいずれにも、lint対象のソースファイルが含まれていない。

ソースファイルの解析にTSConfigファイルが指定されている場合、`@typescript-eslint/parser`は、そのソースファイルを含めることができる最初のTSConfig（aka.ms/tsconfig#includeを参照）を使用して型情報を生成します。ただし、指定されたTSConfigのいずれにもソースファイルが含まれていない場合、パーサーは型情報を生成できません。

このエラーは、プロジェクトのTSConfigに含まれていない設定ファイルなどで最もよく発生します。たとえば、多くのプロジェクトには次のようなファイルがあります。

  • `parserOptions.project: ["./tsconfig.json"]`を含む`.eslintrc.cjs` / `eslint.config.js`
  • `include: ["src"]`を含む`tsconfig.json`

その場合、ESLint拡張機能を使用するIDEでファイルを表示すると、`tsconfig.json`に含まれていないためlintできなかったというエラーが表示されます。

型対応リントに関するドキュメントで詳細情報を確認してください。

「ファイルは、提供されたプロジェクトの少なくとも1つに含まれている必要があります」というエラーが表示されます​

`@typescript-eslint/parser`のバージョンが古くなっています。最新バージョンに更新して、このエラーメッセージのより詳しいバージョンを確認してください。上記で説明されています。

`@typescript-eslint`ルールを有効にするにはどうすればよいですか？​

まず、ドキュメントを読んで、ESLint設定ファイルについて理解していることを確認してください。

ルールのドキュメントでは、「オプション」の見出しの下で、各ルールがサポートするオプションについて詳しく説明しています。TypeScript型を使用して、ルールの設定に使用できるルールの`Options`タプル型を記述しています。設定ファイルでは、`rules`オブジェクトのキーは設定するルールの名前で、値は次の形式に従います。

type Severity = 'off' | 'warn' | 'error';
type RuleConfig =
  | Severity
  | [Severity]
  | [
      Severity,
      // Options is the tuple type from the rule docs
      ...Options,
    ];

いくつかの例

eslint.config.js
export default tseslint.config(
  // ... the rest of your config ...
  {
    rules: {
      // turns a rule on with no configuration (i.e. uses the default configuration)
      '@typescript-eslint/array-type': 'error',
      // turns on a rule with configuration
      '@typescript-eslint/no-explicit-any': ['warn', { ignoreRestArgs: true }],
    },
  },
);

typescript-eslintは、変数が決してnullishではない/`any`であると考えていますが、明らかにそうではありません​

型対応ルールはほとんどの場合、TypeScriptコンパイラから提供される型情報を信頼します。したがって、ルールが正しく動作しているかどうかを確認する簡単な方法は、IDEで変数の上にカーソルを置いて、その型を検査することです。

IDEでも型が決してnullishではない/`any`であると表示される場合は、型を修正する必要があります。非常に一般的なケースは、`no-unnecessary-condition`ルールです。たとえば、次のコードを考えてみてください。

let condition = false;

const f = () => (condition = true);
f();

if (condition) {
  //^^^^^^^^^ Unnecessary conditional, value is always falsy.
}

IDEでカーソルを合わせると、`condition`の型が実際にはリテラル型`false`であることがわかります。この場合、typescript-eslintはTypeScript自体よりも優れた方法を知ることができないため、アサーション（`let condition = false as boolean`など）を使用して型を修正することでレポートを修正する必要があります。

IDEがtypescript-eslintのレポートと異なる型情報を提供する場合、IDE、typescript-eslint、およびtscで使用されるTypeScriptの設定が同じであることを確認してください。TypeScriptのバージョン、型チェックコンパイラのオプション、プロジェクトに含まれるファイルがすべて同じである必要があります。たとえば、ある型が別のファイルで宣言されているが、そのファイルが含まれていない場合、その型はanyになり、no-unsafe-*ルールによるレポートの原因となります。

ESLintの--cacheをtypescript-eslintで使用できますか？​

ESLintの--cacheオプションは、ファイルごとにキャッシュを行います。使用できますが、型チェックを行わないルールに対してのみ確実に機能し、それでも常に機能するとは限りません。

多くのeslint-plugin-importのルールを含む、ファイル間でロジックをチェックするESLintルールは、ファイル間の依存関係を作成します。型付きlintルールは、実際にはほとんどの場合、ファイル間の型に依存しています。ESLintのキャッシュは、これらのファイル間の依存関係を考慮していません。

--cacheの使用はお勧めしません。

カスタムファイル拡張子が必要なフレームワーク（Vueなど）を使用しており、「parserOptions.extraFileExtensionsをconfigに追加する必要があります」のようなエラーが発生します​

parserOptions.extraFileExtensionsを使用して、許可するTypeScript以外の拡張子の配列を指定できます。例：

eslint.config.js
export default tseslint.config(
  // ... the rest of your config ...
  {
    languageOptions: {
      parserOptions: {
        tsconfigRootDir: import.meta.dirname,
        project: ['./tsconfig.json'],
        extraFileExtensions: ['.vue'],
      },
    },
  },
);

.vueファイル内のTypeScriptを解析中にエラーが発生します​

.vueファイルを解析する際に問題が発生する場合は、vue-eslint-parserなどのパーサーが必要な可能性があります。この場合、@typescript-eslint/parserをparserOptions内に移動し、最上位レベルのパーサーとしてvue-eslint-parserを使用できます。

eslint.config.js
import tseslint from 'typescript-eslint';
import vueParser from 'vue-eslint-parser';

export default tseslint.config(
  // ... the rest of your config ...
  {
    languageOptions: {
      parser: tseslint.parser,
      parser: vueParser,
      parserOptions: {
        parser: tseslint.parser,
        sourceType: 'module',
      },
    },
  },
);

parserOptions.parserオプションは、複数のパーサーを指定するオブジェクトも指定できます。詳細については、vue-eslint-parserの使用ガイドを参照してください。

純粋なJavaScriptファイルでlintルールが正しく機能しません​

これは予想される動作です。ESLintルールは、意図的にファイル拡張子を検査しません。これは、非標準の拡張子を使用する環境（たとえば、.vueファイルと.mdファイルの両方にlint対象のTypeScriptコードが含まれている可能性がある）で問題を引き起こすためです。

特定のlintルールを適用したくない純粋なJavaScriptコードがある場合は、ESLintのoverrides設定を使用して、特定のルールを無効にするか、globパターンに基づいてパーサーを変更できます。

トランスパイルされた出力JavaScriptファイルでESLintを実行する必要がありますか？​

いいえ。

ソースTypeScriptファイルには、出力JavaScriptファイルのすべてのコンテンツと、型注釈が含まれています。出力JavaScriptファイルもlintするメリットはありません。

TypeScriptはローカルにインストールする必要があります​

npm install typescript（npm install -g typescriptではなく）またはyarn add typescript（yarn global add typescriptではなく）を使用して、TypeScriptをローカルにインストールしていることを確認してください。#2041で詳細情報を確認してください。

どのように<特定の言語機能>を禁止できますか？​

ESLintコアには、no-restricted-syntaxルールが含まれています。この汎用ルールを使用すると、禁止するコードのセレクターとカスタムエラーメッセージを指定できます。

typescript-eslint playgroundの左側のサイドバーにあるオプション > AST ExplorerでESTreeを選択することにより、禁止するASTの構造を把握するのに役立つAST可視化ツールを使用できます。

たとえば、次の設定のいずれかを使用して、列挙型（またはそのバリエーション）を禁止できます。

{
  "rules": {
    "no-restricted-syntax": [
      "error",
      // ban all enums
      {
        "selector": "TSEnumDeclaration",
        "message": "My reason for not using any enums at all",
      },

      // ban just const enums
      {
        "selector": "TSEnumDeclaration[const=true]",
        "message": "My reason for not using const enums",
      },

      // ban just non-const enums
      {
        "selector": "TSEnumDeclaration:not([const=true])",
        "message": "My reason for not using non-const enums",
      },
    ],
  },
}

ESLint出力にTypeScriptエラーが表示されないのはなぜですか？​

TypeScriptのコンパイラ（またはビルドチェーン）は、コードベースの正確性を検証するために特別に設計および構築されています。当社のツールは、TypeScriptが提供するエラーを再現しません。これは、lintの実行速度が低下し[1]、TypeScriptが既に出力しているエラーが重複するためです。

代わりに、当社のツールは、コードの実行時正確性を検証するだけでなく、新しい方法で型情報を使用するlintルールを使用して、TypeScriptの組み込みチェックを**強化**するために存在します。

[1] - TypeScriptは型情報を遅延計算するため、コンパイラから生成されるエラーを要求すると、ファイルごとにさらに約100msかかります。これは多くないように聞こえますが、コードベースのサイズによっては、lintの実行時間に数秒から数分を追加する可能性があります。

グローバル変数が定義されていないというno-undefルールのエラーが発生しますが、TypeScriptエラーはありません​

no-undef lintルールは、存在するグローバル変数を判断するためにTypeScriptを使用しません。代わりに、ESLintの設定に依存します。

TypeScriptプロジェクトではno-undef lintルールを使用しないことを強くお勧めします。このルールで提供されるチェックは、TypeScriptによって既に提供されており、設定は必要ありません。TypeScriptはこれをはるかに効率的に行います。

v4.0.0リリース以降、これは型にも適用されます。サードパーティパッケージからグローバル型を使用する場合（つまり、@typesパッケージからのもの）、これらのグローバル型を適切にESLintで定義する必要があります。たとえば、@types/reactからのJSX名前空間は、ESLintの設定で定義する必要があるグローバルなサードパーティ型です。

JavaScriptとTypeScriptの両方を含む混合プロジェクトの場合、no-undefルール（他のルールと同様に）は、TypeScriptファイルに対してのみ次のように無効にすることができます。

eslint.config.js
import tseslint from 'typescript-eslint';

export default tseslint.config(
  // ... the rest of your config ...
  {
    files: ['**/*.{ts,tsx,mts,cts}'],
    rules: {
      'no-undef': 'off',
    },
  },
);

ESLintのno-undef lintルールを有効のままにする場合は、ESLintの設定で許可されるglobalsのセットを手動で定義するか、事前に定義された環境（env）設定のいずれかを使用できます。

インストールされているバージョンを確認するにはどうすればよいですか？​

複数のバージョンのツールがある場合、さまざまなバグが発生する可能性があります。これは、ESLintが実行方法に応じて毎回異なるバージョンを読み込む可能性があり、lintの結果が不整合になるためです。

プロジェクトのルートにツールをインストールしても、1つのバージョンのみがインストールされるわけではありません。1つ以上の依存関係がツールに対する独自の依存関係を持つ可能性があり、npm/yarnによってそのバージョンが追加でインストールされ、そのパッケージで使用されます。たとえば、react-scripts（create-react-appの一部）は、当社のツールに依存しています。

次のコマンドを使用して、プロジェクトにインストールされているバージョンを確認できます。

npm list @typescript-eslint/eslint-plugin @typescript-eslint/parser

複数のバージョンがインストールされている場合は、yarn resolutionsを使用して単一のバージョンを強制するか、依存関係のバージョンと一致するようにルートバージョンをダウングレードする必要があります。

この場合、最善の策は、依存関係が最新のバージョンをサポートする新しいバージョンをリリースするまで待つことです。

TypeScriptバージョン/parserOptions.typescriptLocationを指定するにはどうすればよいですか？​

指定できませんし、指定する必要もありません。

プロジェクトの残りの部分と同じバージョンのTypeScriptをlintに使用してください。TypeScriptバージョンには、エッジケースでわずかな違いがあり、typescript-eslintルールとエディターの情報間に矛盾した情報が発生する可能性があります。例：

  • @typescript-eslint/strict-boolean-expressionsはTypeScriptバージョンXで動作し、変数がstring[] | undefinedであると考えている可能性があります。
  • TypeScript自体はバージョンX+1-betaであり、変数がstring[]であると考えている可能性があります。

詳細については、このissueコメントを参照してください。

IDEで他のファイルをlintしても、1つのファイルへの変更が反映されない​

要約: ESLintサーバーを再起動して更新を強制します。

現在のESLintには、ディスク上の任意のファイルが変更されたことを、私たちのようなパーサーに伝える方法がありません。つまり、ファイルBによってインポートされるファイルAを変更した場合、ファイルBのテキスト内容が変更されても、ファイルBのlintキャッシュは更新されません。場合によっては、ESLintエディター拡張機能全体を再起動するしかない場合があります。

詳細はこのissueコメントを参照してください。

ヒント

VS CodeのESLint拡張機能は、ESLint: ESLintサーバーの再起動アクションを提供しています。

ファイル間の変更に対してno-unsafe-*に関する警告が表示される​

1つのファイルへの変更が他のファイルのlintに反映されないを参照してください。no-unsafe-argument、no-unsafe-assignment、no-unsafe-callなどのルールが頻繁に影響を受けます。

"'<key>'プロパティは'<type>'ノードで非推奨です。代わりに'<key>'を使用してください。"という警告​

この警告が表示される場合、typescript-eslint v6用に更新されていないESLintプラグイン（またはその他のツール）を使用している可能性があります。ESLintプラグイン（およびその他のツール）の最新バージョンを使用していることを確認してください。

多くのESLintプラグインを使用していて、それぞれを最新バージョンに更新しており、どのプラグインからこの警告が発生しているかわからない場合は、次のいずれか、または両方を実行してみてください。

  • --trace-deprecationを使用して実行する（例：npx cross-env NODE_OPTIONS=--trace-deprecation npm run lint）
  • プラグインを特定するために、一度に半分ずつ無効にする

その後、それらのプラグインそれぞれに、typescript-eslint v6をサポートするバージョンをリリースするように求めるGitHub issueを作成してください。

ヒント

typescript-eslint v5も引き続きサポートする必要があるプラグインでESLintルールを更新する開発者向け：新しいプロパティキーが存在しない場合は、古いプロパティキーにフォールバックするために||を使用する必要がある場合があります。

- node.typeParameters
+ node.typeArguments || node.typeParameters

詳細については、typeParametersではなくtypeArgumentsという名前のいくつかのプロパティに関するissueと、それを実装するfix: 必要に応じてtypeParametersをtypeArgumentsに名前変更 pull requestを参照してください。

typescript-eslint v6リリース投稿には、typescript-eslint v6に関する詳細情報があります。

リンティングが非常に遅い​

パフォーマンスに問題があると思われる場合は、パフォーマンスに関するトラブルシューティングドキュメントを参照してください。

TypeScriptプロジェクト参照はサポートされていますか？​

はい、ただしEXPERIMENTAL_useProjectServiceを使用する場合のみ。

詳細については、issue #2094（プロジェクト参照に関する議論）を参照してください。