eslint plugin import

Eslint-Plugin-Import

このプラグインは、ES2015+（ES6+）のインポート/エクスポート構文の糸くずをサポートし、ファイルパスとインポート名のスペルミスの問題を防ぐことを目的としています。 ES2015+静的モジュールの構文が提供することを意図しているすべての良さは、エディターにマークアップされています。

崇高でこれを使用している場合：重要な情報については、下のセクションを参照してください。

ルール

で有効になっている構成。
ショ和警告するように設定された構成。
で無効になっている構成。
error errors構成で設定します。
[ recommended構成で設定されています。
typescript構成で設定されています。
？ warnings構成で設定します。
？ --fix CLIオプションによって自動的に修正可能。
編集者の提案によって手動で修正可能。
非推奨。

役立つ警告

名前	説明		ショ和		？
輸出	無効なエクスポート、つまり同じ名前の再輸出を禁止します。	❗☑❗️
非削除されていません	@deprecatedドキュメントタグでマークされたインポート名を禁止します。
空っぽの名前はありません	空の名前付きインポートブロックを禁止します。				？
extraneous依存性なし	無関係なパッケージの使用を禁止します。
マッテブルエクスポートなし	varまたはletを使用して、可変輸出の使用を禁止します。
名前が名付けられていない	デフォルトエクスポートの識別子としてのエクスポート名の使用を禁止します。		☑§？
名前を付けないメンバー	デフォルトエクスポートのプロパティとしてのエクスポート名の使用を禁止します。		☑§？
不使用のモジュールなし	エクスポートなしのモジュールを禁止するか、別のモジュールでのインポートを一致させることなくエクスポートします。

モジュールシステム

名前	説明		ショ和		？
NO-AMD	AMDが呼び出しをrequire 、 define 。
no-commonjs	禁止commonjsには、呼び出しとmodule.exportsまたはexports.* require 。
Import-Module -Exportsなし	CommonJS Module.Exportsを使用したインポートステートメントを禁止します。				？
NO-NODEJS-MODULES	node.jsビルドインモジュールを禁止します。
明確な	潜在的に曖昧な解析目標（ script対module ）を禁止します。

静的分析

名前	説明		ショ和		？
デフォルト	デフォルトのインポートがある場合、デフォルトのエクスポートが存在することを確認します。	❗☑❗️
Node-Node-Protocol-Usageを強制します	node.jsビルトインモジュールをインポートするときに、 node:プロトコルを使用するか、省略しているかのいずれかを強制します。				？
名前が付けられました	名前付きインポートは、リモートファイルの名前付きエクスポートに対応していることを確認してください。	❗☑❗️		⌨⌨️
名前空間	インポートされた名前空間には、再参入されているため、再参入されたプロパティが含まれていることを確認してください。	❗☑❗️
無吸収パス	絶対パスを使用したモジュールのインポートを禁止します。				？
ノーサイクル	モジュールが依存関係パスを持つモジュールをそれ自体にインポートすることを禁止します。
ダイナミックの要求なし	式を使用require()呼び出しを禁止します。
内部モジュール	他のモジュールのサブモジュールのインポートを禁止します。
関連性のないパッケージ	相対パスを介してパッケージのインポートを禁止します。				？
関係のない親の輸入	親ディレクトリからのモジュールのインポートを禁止します。
制限されていないパス	特定のフォルダーにインポートできるファイルを強制します。
No-Self-Import	モジュールがそれ自体のインポートを禁止します。
未解決のものではありません	解決できるファイル/モジュールのインポートポイントを確認してください。	❗☑❗️
無益なパスセグメント	輸入における不必要なパスセグメントを禁止し、ステートメントが必要です。				？
no-webpack-loader-syntax	インポートのWebpackローダーの構文を禁止します。

スタイルガイド

名前	説明		ショ和		？
一貫性のあるタイプの仕上げスタイル	指定された輸入品のインラインタイプのみのマーカーの使用を強制または禁止します。				？
Dynamic-Import-Chunkname	動的なインポートのためにWebPackChunknameで主要なコメントを強制します。
エクスポートラスト	他の声明の後にすべてのエクスポートが表示されるようにします。
拡張機能	インポートパス内でファイル拡張機能の一貫した使用を確認します。
初め	他の声明の前にすべての輸入が表示されるようにします。				？
Group-Exports	単一の輸出宣言でグループ化される名前の輸出を好む
インポートファースト	import/firstに置き換えられました。				？
最大依存関係	モジュールが持つことができる依存関係の最大数を実施します。
Newline-After-Import	インポートステートメントの後に新しいラインを実施します。				？
No-Anonymous-Default-Export	デフォルトエクスポートとして匿名値を禁止します。
Do-Default-Export	デフォルトエクスポートを禁止します。
ダイプリケートなし	複数の場所で同じモジュールの繰り返しインポートを禁止します。		☑§？		？
無名のdefault	デフォルトエクスポートという名前の禁止。
No-Named-Export	輸出と名付けられた禁止。
NO-NAMESPACE	禁止名空間（別名「ワイルドカード」 * ）のインポート。				？
assigned-importなし	未割り当ての輸入を禁止します
注文	モジュールのインポート順序で条約を実施します。				？
Prefer-Default-Export	モジュールが単一の名前または複数の名前をエクスポートする場合、デフォルトのエクスポートを優先します。

eslint-plugin-import for Enterprise

Tideliftサブスクリプションの一部として利用可能。

eslint-plugin-importおよび他の何千ものパッケージのメンテナーは、Tideliftと協力して、アプリケーションを構築するために使用するオープンソースの依存関係に商業サポートとメンテナンスを提供しています。時間を節約し、リスクを減らし、コードの健康を改善しながら、使用する正確な依存関係のメンテナーに支払います。もっと詳しく知る。

インストール

 # inside your project's working tree
npm install eslint-plugin-import --save-dev

config-レガシー（ .eslintrc ）

すべてのルールはデフォルトでオフになっています。ただし、プリセット構成の1つを拡張するか、 .eslintrc.(yml|json|js)で手動で構成することもできます。

• プリセット構成の拡張：

 {
  "extends" : [
     "eslint:recommended" ,
     "plugin:import/recommended" ,
  ] ,
}

• 手動で構成：

 {
  "rules" : {
    "import/no-unresolved" : [ "error" , { "commonjs" : true , "amd" : true } ] ,
    "import/named" : "error" ,
    "import/namespace" : "error" ,
    "import/default" : "error" ,
    "import/export" : "error" ,
    // etc...
  } ,
} ,

config-フラット（ eslint.config.js ）

すべてのルールはデフォルトでオフになっています。ただし、 eslint.config.(js|cjs|mjs)で手動で構成するか、プリセット構成のいずれかを拡張できます。

 import importPlugin from 'eslint-plugin-import' ;
import js from '@eslint/js' ;

export default [
  js . configs . recommended ,
  importPlugin . flatConfigs . recommended ,
  {
    files : [ '**/*.{js,mjs,cjs}' ] ,
    languageOptions : {
      ecmaVersion : 'latest' ,
      sourceType : 'module' ,
    } ,
    rules : {
      'no-unused-vars' : 'off' ,
      'import/no-dynamic-require' : 'warn' ,
      'import/no-nodejs-modules' : 'warn' ,
    } ,
  } ,
] ; 

タイプスクリプト

次のスニペットを使用するか、以下に説明する粒状設定を使用して独自の構成を組み立てることができます。

次の構成で使用される@typescript-eslint/parserおよびeslint-import-resolver-typescriptをインストールしていることを確認してください。

 {
  "extends" : [
    "eslint:recommended" ,
    "plugin:import/recommended" ,
// the following lines do the trick
    "plugin:import/typescript" ,
  ] ,
  "settings" : {
    "import/resolver" : {
      // You will also need to install and configure the TypeScript resolver
      // See also https://github.com/import-js/eslint-import-resolver-typescript#configuration
      "typescript" : true ,
      "node" : true ,
    } ,
  } ,
}

config config() in typescript-eslintをwith flat

typescript-eslintのconfigメソッドを使用している場合は、 flatConfigがextends配列内に含まれていることを確認してください。

 import tseslint from 'typescript-eslint' ;
import importPlugin from 'eslint-plugin-import' ;
import js from '@eslint/js' ;

export default tseslint . config (
  js . configs . recommended ,
  // other configs...
  {
    files : [ '**/*.{ts,tsx}' ] ,
    extends : [ importPlugin . flatConfigs . recommended ] ,
    // other configs...
  }
) ; 

リゾルバー

モジュールのバンドラーの出現とモジュールとモジュールの構文仕様の現在の状態により、 import x from 'module'場所がmodule背後にあるファイルを見つける場所を常に明らかにするとは限りません。

v0.10ishを介して、このプラグインはSubscackのresolveプラグインを直接使用しており、Nodeのインポート動作を実装しています。これは、ほとんどの場合、非常にうまく機能します。

ただし、Webpackは、ローダー（ import 'file!./whatever' ）やexternalsなどの多くのエイリアシングスキームなど、ノードにはないインポートモジュールソース文字列の多くのものを許可します。モジュールIDをランタイムにグローバル名にマッピングします（スクリプトタグを介していくつかのモジュールをより伝統的に含めることができます）。

これらの両方をサポートするために、v0.11はリゾルバーを導入します。

現在、ノードとWebパックの解像度が実装されていますが、リゾルバーはNPMパッケージであるため、サードパーティのパッケージがサポートされています（および奨励されています！）。

いくつかの方法でリソースバーを参照できます（優先順位で）：

• eslint-import-resolver eslint-import-resolver-foo名前として：

 // .eslintrc
{
 "settings" : {
   // uses 'eslint-import-resolver-foo':
   "import/resolver" : "foo" ,
 } ,
} 

 # .eslintrc.yml
settings :
  # uses 'eslint-import-resolver-foo':
  import/resolver : foo 

 // .eslintrc.js
module . exports = {
  settings : {
    'import/resolver' : {
      foo : { someConfig : value }
    }
  }
}

• my-awesome-npm-moduleのような完全なnpmモジュール名を使用してください。

 // .eslintrc
{
  "settings" : {
    "import/resolver" : "my-awesome-npm-module" ,
  } ,
} 

 # .eslintrc.yml
settings :
  import/resolver : ' my-awesome-npm-module ' 

 // .eslintrc.js
module . exports = {
  settings : {
    'import/resolver' : {
      'my-awesome-npm-module' : { someConfig : value }
    }
  }
}

• この例では、 computed property名として定義されているリゾルバーへのファイルシステムパスを使用してください。

 // .eslintrc.js
module . exports = {
  settings : {
    'import/resolver' : {
      [ path . resolve ( '../../../my-resolver' ) ] : { someConfig : value }
    }
  }
}

package.jsonが見つからない場合、Sourceの最寄りのpackage.jsonまたはプロセスの現在の作業ディレクトリに対して、相対パスは解決されます。

リゾルバーを書くのが面白い場合は、詳細についてはスペックをご覧ください。

設定

.eslintrcで次の設定を設定できます。

import/extensions

モジュールとして解析され、 export用に検査されるファイル拡張子のリスト。

これは、 ['.js']にデフォルトであり、 react共有構成を使用していない限り、 ['.js', '.jsx']として指定されています。デフォルトにもかかわらず、TypeScriptを使用している場合（ plugin:import/typescriptスクリプト構成）、新しい拡張機能（ .ts 、およびReactを使用する場合は.tsx ）を指定する必要があります。

 "settings" : {
  "import/extensions" : [
    ".js" ,
    ".jsx"
  ]
}

より詳細な拡張定義が必要な場合は、以下を使用できます。

 "settings" : {
  "import/resolver" : {
    "node" : {
      "extensions" : [
        ".js" ,
        ".jsx"
      ]
    }
  }
}

これは、 .json 、 .coffeeなどを含む可能性のあるimport/resolver拡張設定とは異なる（およびおそらくno-unresolvedのサブセット）。

また、次のimport/ignoreパターンがこのリストを覆します。

import/ignore

パスに一致する場合、 exportが見つからない場合は一致するモジュールを報告しないREGEX文字列のリスト。実際には、これは、このパターンに一致する（絶対ファイルシステム）パスを使用してno-unresolved以外のルールがimport Sについて報告しないことを意味します。

no-unresolved独自のignore設定を持っています。

 {
  "settings" : {
    "import/ignore" : [
      ".coffee$" , // fraught with parse errors
      ".(scss|less|css)$" , // can't parse unprocessed CSS modules, either
    ] ,
  } ,
}

import/core-modules

「コア」モジュールと見なす追加のモジュールの配列 - 解決されると見なされるべきモジュールは、ファイルシステムにパスがありません。リゾルバーはすでにこれらのいくつかを定義している可能性があります（たとえば、ノードリゾルバーはfsとpathについて知っているため）。したがって、それらを再定義する必要はありません。

たとえば、電子はelectronモジュールを公開します。

 import 'electron'  // without extra config, will be flagged as unresolved!

そうでなければ、それは解決されません。これを回避するために、コアモジュールとしてelectron提供できます。

 // .eslintrc
{
  "settings" : {
    "import/core-modules" : [ "electron" ] ,
  } ,
}

Electronの特定の場合、これを指定するelectronという名前の共有構成があります。

他のプラットフォーム向けのこのような共有構成のより多くの貢献は大歓迎です！

import/external-module-folders

フォルダーの配列。これらのフォルダーからのみ解決されたモジュールは、「外部」と見なされます。デフォルトで - ["node_modules"] 。内部パスを異なる方法で処理するようにパスまたはWebpackを構成し、 bower_componentsやjspm_modulesなどの一部のフォルダーからモジュールを「外部」として検討したい場合に理にかなっています。

このオプションは、Monorepoのセットアップにも役立ちます。Monorepoのパッケージを含むすべてのディレクトリをここにリストし、どのリゾルバーが使用されていても外部のディレクトリとして扱われます。

yarn PNPをパッケージマネージャーとして使用している場合、 .yarnフォルダーを追加し、インストールされているすべての依存関係はinternalではなくexternalと見なされます。

この配列の各アイテムは、フォルダーの名前、サブパス、または絶対的なプレフィックスパスのいずれかです。

• jspm_modules /home/me/project/jspm_modules jspm_modulesという名前のファイルまたはフォルダーと一致するか、 jspm_modulesという名前の直接または非方向の親を抱えてい/home/me/project/jspm_modules/some-pkg/index.js 。

• packages/core /home/me/project/packages/core/src/utils.js /me/project/packages/core/src/utils.jsなど、これら2つのセグメントを含む任意のパスと一致します。

• /home/me/project/packagesこのディレクトリ内のファイルとディレクトリ、およびディレクトリ自体のみを一致させます。

ここでは不完全な名前は許可されていないため、 components bower_componentsとpackages/ui packages/ui-utilsと一致しません（ただし、 packages/ui/utilsと一致します）。

import/parsers

パーサーからファイルエクステンション配列へのマップ。ファイル拡張子が一致している場合、依存関係パーサーは、構成されたESLINTパーサーの代わりに、マップキーをパーサーとして使用し、使用します。これは、Webpackを使用してTypeScriptを直接使用している場合に役立ちます。

 // .eslintrc
{
  "settings" : {
    "import/parsers" : {
      "@typescript-eslint/parser" : [ ".ts" , ".tsx" ] ,
    } ,
  } ,
}

この場合、 @typescript-eslint/parserをインストールし、実行中のeslintモジュールの場所から要求可能にする必要があります（つまり、ESLINTのピアとしてインストールしてください）。

現在、これは@typescript-eslint/parser （およびその前身であるtypescript-eslint-parser ）でのみテストされていますが、理論的には中程度にESTに準拠したパーサーで動作する必要があります。

ウサギの穴がどれだけ離れているかに応じて、さまざまなプラグイン機能がどれだけサポートされるかを言うのは困難です。ここで奇妙な動作を見つけた場合は問題を提出しますが、 wontfixで閉じる可能性のある結果に対して心を鍛えてください。

import/resolver

リゾルバーを参照してください。

import/cache

キャッシュ動作の設定。メモは、エラーを正しく報告するために必要な大量のfs.statSync /モジュールの解析呼び出しを避けるために、さまざまなレベルで使用されます。

通常のeslintコンソールが実行される場合、キャッシュの寿命は無関係です。これは、リンタープロセスの寿命（したがって、メモリ内のキャッシュ）の間にファイルが変わってはならないと強く想定できるためです。

ただし、 eslint_dやeslint-loaderなどの長期にわたるプロセスの場合、頑固さの概念があることが重要です。

eslint_dまたはeslint-loaderを使用しない場合、キャッシュライフタイムをInfinityに設定できます。すべてが問題ないはずです。

 // .eslintrc
{
  "settings" : {
    "import/cache" : {
      "lifetime" : "∞" , // or Infinity, in a JS config
    } ,
  } ,
}

それ以外の場合は、整数を設定し、キャッシュエントリが数秒が経過した後に追い出されます。

 // .eslintrc
{
  "settings" : {
    "import/cache" : {
      "lifetime" : 5 , // 30 is the default
    } ,
  } ,
}

import/internal-regex

パッケージの正規表現は、内部として扱う必要があります。モノレポのセットアップを利用したり、互いに依存しているパッケージのセットを開発したりする場合に役立ちます。

デフォルトでは、 import/external-module-foldersから参照されるパッケージは、糸ワークスペースやレルナ環境のようなモノレポのパッケージを含む「外部」と見なされます。これらのパッケージを「内部」としてマークしたい場合は、これが役立ちます。

たとえば、Monorepoのパッケージがすべて@scopeにある場合、このようなimport/internal-regexを構成できます

 // .eslintrc
{
  "settings" : {
    "import/internal-regex" : "^@scope/" ,
  } ,
}

import/node-version

使用しているnode.jsのバージョンを表す文字列。 falsy値は、eslintを実行しているnode.jsのバージョンを意味します。

 // .eslintrc
{
  "settings" : {
    "import/node-version" : "22.3.4" ,
  } ,
} 

sublimelinter-eslint

sublimelinter-eslintは、編集中にリントするときにファイルパスがeslintに渡される方法を変更する.eslintignoreファイルをサポートするための変更を導入しました。この変更により、ファイルへの絶対パスの代わりに相対パスが送信されます（Eslintが通常提供するように）。このプラグインがファイルシステムの依存関係を解決することを不可能にする可能性があります。

ESLINT 2.0のリリースでは、この回避策は、 .eslintignoreが.gitignoreのように機能するように更新されるときにもはや必要ではありません--stdin-filename

それまでの間、詳細とディスカッションについては、RoadHump/Sublimelinter-Eslint＃58を参照してください。基本的には、以下のSublimeLinter構成を崇高なプロジェクトファイルに追加する必要がある場合があります。

{
    "folders" :
    [
        {
            "path" : " code "
        }
    ],
    "SublimeLinter" :
    {
        "linters" :
        {
            "eslint" :
            {
                "chdir" : " ${project}/code "
            }
        }
    }
}

${project}/code folders[0].pathで提供されるcodeと一致することに注意してください。

この場合、 chdir設定の目的は、ESLINTが実行される作業ディレクトリを設定することです。

これがプロジェクトで動作しない場合に備えて、詳細については、 chdirのsublimelinterドキュメントを参照してください。

.eslintignoreを使用していない場合、または崇高なプロジェクトファイルを持っていない場合は、コードの祖先ディレクトリで.sublimelinterrcファイルを介して以下を実行することもできます。

{
  "linters" : {
    "eslint" : {
      "args" : [ " --stdin-filename " , " @ " ]
    }
  }
}

また、 rc_search_limit nullに設定する必要があることがわかりました。これにより、 .sublimelinterrc ：sublimelinterrcのディレクトリツリーを検索するときにファイル階層検索制限が削除されます。

パッケージ設定 / sublimelinter /ユーザー設定：

{
  "user" : {
    "rc_search_limit" : null
  }
}

これは3であると思うので、プロジェクトフォルダーの最大深度に応じて変更する必要はないかもしれません。