eslint plugin import

Eslint-Plugin-Import

該插件打算支持ES2015+（ES6+）導入/導出語法的覆蓋，並防止文件路徑和導入名稱的拼寫問題。 ES2015+靜態模塊語法的所有優點都打算提供編輯器中標記的。

如果您正在使用Sublime使用此信息：有關重要信息，請參見底部。

規則

啟用了配置。
配x設置為警告的配置。
配置禁用。
❗在errors配置中設置。
☑️在recommended配置中設置。
⌨️在typescript配置中設置。
？設置在warnings配置中。
？通過--fix CLI選項自動固定。
由編輯建議手動修復。
棄用。

有用的警告

姓名	描述		配x		？
出口	禁止任何無效的出口，即重新出口同名。	❗☑️
沒有被剝奪	禁止導入的名稱標記為@deprecated文檔標籤。
無空的街區	禁止空名為導入塊。				？
無依賴性	禁止使用外包包。
不可撤離	禁止使用可變的出口與var或let 。
無名為默認	禁止使用導出名稱作為默認導出的標識符。		☑️？
沒有命名為默認會員	禁止使用導出名稱作為默認導出的屬性。		☑️？
沒有懸掛模型	禁止沒有導出的模塊，或在另一個模塊中導入而無需匹配導出。

模塊系統

姓名	描述		配x		？
沒有amd	禁止AMD require並define呼叫。
無命令	禁止concomjs require呼叫和module.exports或exports.* 。
無IMPORT模塊	禁止使用commonjs模塊的導入語句。				？
Noondodejs模型	禁止node.js內置模塊。
明確	禁止潛在模棱兩可的解析目標（ script與module ）。

靜態分析

姓名	描述		配x		？
預設	給定默認導入，請確保存在默認導出。	❗☑️
執行節點求和概述	在導入node.js內置模塊時使用或省略node:協議。				？
命名	確保命名導入對應於遠程文件中的指定導出。	❗☑️		⌨️
名稱空間	確保導入的命名空間包含重新給出的屬性。	❗☑️
無滲透路徑	禁止使用絕對路徑導入模塊。				？
無週期	禁止一個模塊導入具有依賴關係路徑回到自身的模塊。
沒有動態重複	禁止使用表達式require()呼叫。
無內部模型	禁止進口其他模塊的子模塊。
無核包裝	禁止通過相對路徑導入軟件包。				？
無宗教派派對	禁止從父目錄導入模塊。
無限制的路徑	強制可以在給定文件夾中導入哪些文件。
沒有自我像徵	禁止一個模塊導入。
尚未解決	確保導入指向可以解決的文件/模塊。	❗☑️
沒有無用的路徑	禁止進口中不必要的路徑段，需要語句。				？
沒有webpack-loader-syntax	禁止導入中的WebPack加載程序語法。

樣式指南

姓名	描述		配x		？
一致的型特性型	強製或禁止使用僅類型的標記來命名導入。				？
動態象徵 - 名稱	使用WebPackChunkname執行領先的評論，以進行動態導入。
出口持久	確保在其他語句之後出現所有出口。
擴展	確保在導入路徑中持續使用文件擴展名。
第一的	確保所有進口都出現在其他語句之前。				？
小組遠離	優先命名出口是將單個出口聲明分組在一起
進口第一	由import/first取代。				？
最大依賴性	強制模塊可以擁有的最大依賴項數量。
紐線 - 象徵	在導入語句之後執行新線。				？
無匿名默認要出口	禁止匿名值作為默認導出。
無默認要出口	禁止默認導出。
沒有探討	禁止在多個位置重複進口同一模塊。		☑️？		？
沒有命名默認	禁止命名默認導出。
沒有命名	禁止命名出口。
無名空間	禁止名稱空間（又稱“通配符” * ）導入。				？
沒有未協調的象徵	禁止未分配的進口
命令	在模塊導入順序中執行約定。				？
優先默認遠端	如果模塊導出單個名稱或多個名稱，則希望默認導出。

eslint-plugin-import for Enterprise

作為Tidelift訂閱的一部分可用。

eslint-plugin-import的維護者和其他成千上萬的軟件包正在與Tidelift合作，為您用於構建應用程序的開源依賴關係提供商業支持和維護。節省時間，降低風險並改善代碼健康，同時支付您使用的確切依賴項的維護者。了解更多。

安裝

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

配置-Legacy（ .eslintrc ）

默認情況下，所有規則都不在。但是，您可以擴展預設配置之一，或者在.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 -flat（ 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 -flat with config()在typescript-eslint中

如果您正在使用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的情況下，該插件直接使用了替代的resolve插件，該插件實現了Node的導入行為。在大多數情況下，這效果很好。

但是，WebPack允許在導入模塊源字符串中進行許多內容，例如加載程序（ import 'file!./whatever' ）和許多混疊程序，例如externals ：將模塊ID映射到運行時的全局名稱（允許通過腳本標籤更包含一些模塊））。

為了支持這兩種情況，v0.11引入了解析器。

目前已經實施了節點和WebPack分辨率，但是解析器只是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 }
    }
  }
}

• 具有完整的NPM模塊名稱，例如my-awesome-npm-module ：

 // .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解決。 JSON或該過程的當前工作目錄，如果找不到package.json 。

如果您在編寫解析器方面很有趣，請參閱規格以獲取更多詳細信息。

設定

您可以在.eslintrc中設置以下設置：

import/extensions

文件擴展名列表將被解析為模塊並檢查export s。

除非您使用react共享配置，否則默認為['.js'] ，在這種情況下，它被指定為['.js', '.jsx'] 。儘管默認，但是如果您使用的是typescript（沒有plugin:import/typescript配置上述），則必須指定新的擴展名（ .ts ，以及.tsx如果使用react）。

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

如果您需要更多的顆粒擴展定義，則可以使用：

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

請注意，這與可能包括.json ， .coffee等的任何import/resolver擴展設置不同（並且可能是一個子集），這仍然會導致no-unresolved規則。

同樣，以下import/ignore模式將覆蓋此列表。

import/ignore

如果未找到export s，則將與路徑匹配的正則列表將不會報告匹配模塊。實際上，這意味著除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 ，為您指定了這一點。

歡迎更多此類共享配置為其他平台的貢獻！

import/external-module-folders

一個文件夾。僅從這些文件夾中解析的模塊將被視為“外部”。默認情況下 - ["node_modules"] 。如果您配置了路徑或WebPack以不同的方式處理內部路徑，並且想考慮一些文件夾中的模塊，例如bower_components或jspm_modules ，則是有道理的。

此選項在MonorePo設置中也很有用：列表此處所有包含MonorePo軟件包的目錄，無論使用哪種解析器，它們都將被視為外部。

如果您使用yarn PNP作為軟件包管理器，請添加.yarn文件夾，所有安裝的依賴項將被視為external ，而不是internal 。

此數組中的每個項目都是文件夾的名稱，其子路口或其絕對前綴路徑：

• JSPM_MODULES將匹配名為JSPM_MODULES的任何文件或文件夾，或具有名為JSPM_MODULES的直接或非直接父級，EG /HOME/ME/ME/PROVECT/ jspm_modules OR/HOME/HOME/ME/me/project/ jspm_modules / jspm_modules /home/me/project/jspm_modules /home/me/project/jspm_modules/some-pkg/index.js

• packages/core將匹配包含這兩個段的任何路徑，例如/home/me/project/packages/core/src/utils.js 。

• /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" ] ,
    } ,
  } ,
}

在這種情況下，必須在運行的eslint模塊的位置安裝@typescript-eslint/parser並需要（即，將其作為ESLINT的peer安裝）。

目前僅使用@typescript-eslint/parser （及其前身typescript-eslint-parser ）對此進行測試，但理論上應與任何中等符合Estree的解析器一起使用。

很難說出各種插件功能的支持，具體取決於兔子孔的距離多遠。如果您在這裡發現奇怪的行為，請提交問題，但要與wontfix結束的可能結果有關。

import/resolver

請參閱解析器。

import/cache

緩存行為的設置。在各個級別使用紀念活動，以避免使用正確報告錯誤所需的大量fs.statSync /模塊解析。

對於正常的eslint控制台運行，高速緩存壽命是無關緊要的，因為我們可以強烈認為文件在Linter過程的壽命中不應更改（因此，內存中的緩存）

但是，對於持久的過程，例如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

包裹的正則應視為內部。當您使用MonorePo設置或開發一組彼此依賴的軟件包時，很有用。

默認情況下，從import/external-module-folders引用的任何軟件包都將被視為“外部”，包括紗線工作區或LERNA環境等MonorePo中的軟件包。如果您想將這些軟件包標記為“內部”，則將很有用。

例如，如果您的軟件包在monorepo中都在@scope中，則可以配置import/internal-regex

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

import/node-version

表示您正在使用的node.js版本的字符串。虛假的值將暗示您正在運行Eslint的Node.js版本。

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

sublimelinter-eslint

sublimelinter-eslint引入了一個更改，以更改支持.eslintignore文件，該文件在編輯過程中更改了文件路徑的方式將文件路徑傳遞給ESLINT。此更改發送了一個相對路徑，而不是通往文件的絕對路徑（如通常提供的ESLINT），這可能使該插件無法解決對文件系統的依賴關係。

在發布ESLINT 2.0時，不再需要此解決方法，當.eslintignore將更新以更像.gitignore工作方式，該工作應該通過--stdin-filename來支持適當地忽略絕對路徑。

同時，有關更多詳細信息和討論，請參見Roadhump/Sublimelinter-Eslint＃58，但從本質上講，您可能會發現您需要將以下SublimeLinter配置添加到Sublime Project文件中：

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

請注意， ${project}/code與folders[0].path提供的code匹配。

在這種情況下， chdir設置的目的是設置執行ESLINT的工作目錄與Sublimelinter-Eslint基礎所提供的相對路徑的目錄相同。

有關更多信息，請參見chdir上的Sublimelinter文檔，以防您的項目不起作用。

如果您不使用.eslintignore ，或者沒有崇高的項目文件，也可以通過代碼的某些祖先目錄中的.sublimelinterrc文件進行以下操作：

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

我還發現我需要將rc_search_limit設置為null ，該null在查找.sublimelinterrc的目錄樹時刪除了文件層次結構搜索限制：

在軟件包設置 / sublimelinter /用戶設置中：

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

我相信這默認為3 ，因此您可能不需要根據項目文件夾最大深度更改它。