eslint plugin import
v2.31.0
Dieses Plugin beabsichtigt, die Linie von ES2015+ (ES6+) import/exportieren Syntax importieren/exportieren und Probleme beim Fehlschreiben von Dateipfaden und -Anwuchs verhindern. Die gesamte Güte, die die Syntax der statischen Modul ES2015+ beabsichtigt, die in Ihrem Editor markiert zu werden.
Wenn Sie dies mit Sublime verwenden : Wichtige Informationen finden Sie im unteren Bereich.
Konfigurationen aktiviert in.
Konfigurationen deaktiviert in.
❗ Einstellen in der errors .
☑️ In der recommended Konfiguration einstellen.
⌨️ In der typescript -Konfiguration einstellen.
? Setzen Sie in der warnings .
? Automatisch durch die Option --fix CLI behoben werden.
Manuell durch Redakteurvorschläge behoben werden.
Veraltet.
| Name | Beschreibung | ? | |||||
|---|---|---|---|---|---|---|---|
| Export | Verbieten Sie alle ungültigen Exporte, dh gleichnamige Wiederbelebung. | ❗ ☑️ | |||||
| No-Deprecated | Verbot importierte Namen mit @deprecated Dokumentation Tag. | ||||||
| No-leer-benannte Blocks | Verbieten leere benannte Importblöcke. | ? | |||||
| Nicht-extrane Abhängigkeiten | Verbieten die Verwendung von Fremdpaketen. | ||||||
| No-toller-Exports | Verbieten die Verwendung veränderlicher Exporte mit var oder let . | ||||||
| No-Named-as-Default | Verbot der Verwendung des exportierten Namens als Kennung des Standard -Exports. | ☑️? | |||||
| No-Named-as-Default-Mitglied | Verbot der Verwendung des exportierten Namens als Eigenschaft des Standard -Exports. | ☑️? | |||||
| Nicht-ungehörte Modules | Verbot Module ohne Exporte oder exportiert ohne den Import in einem anderen Modul. |
| Name | Beschreibung | ? | |||||
|---|---|---|---|---|---|---|---|
| No-Amd | Verbieten Sie AMD require und define Anrufe. | ||||||
| No-Commonjs | Verbot CommonJs require Anrufe und module.exports oder exports.* . | ||||||
| No-Import-Module-Exports | Verbot importieren Aussagen mit CommonJS modul.exports. | ? | |||||
| No-NodeJS-Modules | Verbot node.js bauungsmodule. | ||||||
| eindeutig | Verbot potenziell mehrdeutiges Zielziel ( script vs. module ). |
| Name | Beschreibung | ? | |||||
|---|---|---|---|---|---|---|---|
| Standard | Stellen Sie sicher, dass ein Standard -Export vorhanden ist, wenn ein Standardimport entspricht. | ❗ ☑️ | |||||
| Durchsetzung des Node-Protokoll-Gebrauchs | Durchsetzen Sie den node: Protokoll bei der Importation von Knoten.js -ingebauten Modulen. | ? | |||||
| namens | Stellen Sie sicher, dass benannte Importe einem benannten Export in der Remotedatei entsprechen. | ❗ ☑️ | ⌨️ | ||||
| Namespace | Stellen Sie sicher, dass importierte Namespaces diefertigten Eigenschaften enthalten, sobald diese Derferen sind. | ❗ ☑️ | |||||
| Nicht-Absolute-Pfad | Verbot der Import von Modulen unter Verwendung absoluter Pfade. | ? | |||||
| No-Cycle | Verbieten Sie einem Modul, ein Modul mit einem Abhängigkeitspfad zurück zu sich selbst zu importieren. | ||||||
| No-Dynamic-Erregung | Verbot require() Anrufe mit Ausdrücken. | ||||||
| Nicht-Internal-Modul | Verbieten, die Submodules anderer Module zu importieren. | ||||||
| No-Relativpakete | Verbieten das Importieren von Paketen über relative Wege. | ? | |||||
| No-Relativ-Eltern-Imports | Importieren Module aus übergeordneten Verzeichnissen verbieten. | ||||||
| Nicht beschränkte Pfaden | Durchsetzen, welche Dateien in einem bestimmten Ordner importiert werden können. | ||||||
| Nicht-Selbst-Import | Verbieten ein Modul, sich selbst zu importieren. | ||||||
| Nicht ungelöster | Stellen Sie sicher, dass Importe auf eine Datei/ein Modul hinweisen, das gelöst werden kann. | ❗ ☑️ | |||||
| No-Uslosen-Pfadsegmente | Verbieten unnötige Pfadsegmente im Import und verlangen Erklärungen. | ? | |||||
| No-Webpack-Lader-Syntax | Verbieten Sie die Webpack -Loader -Syntax in Importen. |
| Name | Beschreibung | ? | |||||
|---|---|---|---|---|---|---|---|
| Konsistentstil | Erzwingen oder Verbot der Verwendung von Inline-Typ-Markern für benannte Importe. | ? | |||||
| Dynamik-Import-Chunkname | Erzwingen Sie einen führenden Kommentar mit dem WebPackChunkName für dynamische Importe. | ||||||
| Exporte länger | Stellen Sie sicher, dass alle Exporte nach anderen Aussagen erscheinen. | ||||||
| Erweiterungen | Stellen Sie eine konsistente Verwendung der Dateierweiterung im Importpfad sicher. | ||||||
| Erste | Stellen Sie sicher, dass alle Importe vor anderen Aussagen erscheinen. | ? | |||||
| Gruppenexports | Bevorzugen Sie benannte Exporte, die in einer einzigen Exporterklärung zusammengefasst werden sollen | ||||||
| Importe-First | Ersetzt durch import/first . | ? | |||||
| maximale Abhängigkeiten | Durchsetzen der maximalen Anzahl von Abhängigkeiten, die ein Modul haben kann. | ||||||
| Newline-After-Import | Erzwingen Sie eine neue Linie nach Importanweisungen. | ? | |||||
| No-Anonymous-Default-Export | Verbieten anonyme Werte als Standard -Exporte. | ||||||
| No-Default-Export | Verbot Standardexporte. | ||||||
| No-Duplikate | Verbot wiederholter Import desselben Moduls an mehreren Stellen. | ☑️? | ? | ||||
| No-Named-Default | Verbieten benannte Standardexporte. | ||||||
| No-Named-Export | Verboten genannte Exporte. | ||||||
| No-Namesspace | Verbot Namespace (auch bekannt als "Wildcard" * ) Importe. | ? | |||||
| Nicht-ungültiger Import | Verbieten nicht zugewiesene Importe | ||||||
| Befehl | Erzwingen Sie eine Konvention in der Modulimportordnung. | ? | |||||
| bevorzugt-Default-Export | Bevorzugen Sie einen Standard -Export, wenn das Modul einen einzelnen Namen oder mehrere Namen exportiert. |
eslint-plugin-import für EnterpriseErhältlich als Teil des Tidelift -Abonnements.
Die Betreuer von eslint-plugin-import und Tausenden anderer Pakete arbeiten mit TIDELIFT zusammen, um kommerzielle Unterstützung und Wartung für die Open-Source-Abhängigkeiten zu liefern, die Sie zum Erstellen Ihrer Anwendungen verwenden. Sparen Sie Zeit, reduzieren Sie das Risiko und verbessern Sie die Gesundheit des Codes, während Sie die Wartenden der genauen Abhängigkeiten, die Sie verwenden, zahlen. Erfahren Sie mehr.
# inside your project's working tree
npm install eslint-plugin-import --save-dev.eslintrc ) Alle Regeln sind standardmäßig ausgeschaltet. Sie können jedoch eine der voreingestellten Konfigurationen erweitern oder sie manuell in Ihrem .eslintrc.(yml|json|js) konfigurieren.
{
"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...
} ,
} ,eslint.config.js ) Alle Regeln sind standardmäßig ausgeschaltet. Sie können sie jedoch manuell in Ihrem eslint.config.(js|cjs|mjs) konfigurieren oder eine der voreingestellten Konfigurationen erweitern:
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' ,
} ,
} ,
] ; Sie können das folgende Snippet verwenden oder Ihre eigene Konfiguration unter Verwendung der unten beschriebenen körnigen Einstellungen zusammenstellen.
Stellen Sie sicher, dass Sie @typescript-eslint/parser und eslint-import-resolver-typescript installiert haben, die in der folgenden Konfiguration verwendet werden.
{
"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() in typescript-eslint Wenn Sie die config von typescript-eslint verwenden, stellen Sie sicher, dass die flatConfig im extends -Array enthalten ist.
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...
}
) ; Mit dem Aufkommen von Modulbundlers und dem aktuellen Status von Modulen- und Modulsyntaxspezifikationen ist es nicht immer offensichtlich, wo import x from 'module' die Datei hinter module finden sollte.
Nach V0.10ISH hat dieses Plugin resolve -Plugin von Substack direkt verwendet, das das Importverhalten des Knotens implementiert. Dies funktioniert in den meisten Fällen ziemlich gut.
WebPack ermöglicht jedoch eine Reihe von Dingen im Importmodul -Quellzeichen, die Node nicht wie Lader ( import 'file!./whatever' ) und eine Reihe von Aliasing -Schemata, wie z. B. externals : Zuordnung einer Modul -ID zu einem globalen Namen zur Laufzeit (ermöglicht, dass einige Module traditionell mehr über Skript -Tags eingeschlossen werden können).
Um beide zu unterstützen, führt V0.11 Resolver vor.
Derzeit wurden eine Node- und Webpack -Lösung implementiert, aber die Resolver sind nur NPM -Pakete, sodass Pakete von Drittanbietern unterstützt (und gefördert werden!).
Sie können auf verschiedene Weise auf Resolver verweisen (in der Reihenfolge der Vorrang):
eslint-import-resolver wie 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 : // .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 }
}
}
} Relative Pfade werden relativ zum nächstgelegenen package.json der Quelle oder zum aktuellen Arbeitsverzeichnis des Prozesses gelöst, wenn kein package.json gefunden wird.
Wenn Sie beim Schreiben eines Resolvers interessant sind, finden Sie in der Spezifikation weitere Details.
Sie können die folgenden Einstellungen in Ihrem .eslintrc festlegen:
import/extensions Eine Liste von Dateierweiterungen, die als Module analysiert und auf export geprüft werden.
Diese Standardeinstellung für ['.js'] , es sei denn, Sie verwenden die react Shared Config. In diesem Fall wird sie als ['.js', '.jsx'] angegeben. Trotz der Standardeinstellung müssen Sie die neuen Erweiterungen ( .ts und auch .tsx bei Verwendung von React) angeben, wenn Sie TypeScript (ohne plugin:import/typescript -Konfiguration) angeben.
"settings" : {
"import/extensions" : [
".js" ,
".jsx"
]
}Wenn Sie mehr detaillierte Verlängerungsdefinitionen benötigen, können Sie verwenden:
"settings" : {
"import/resolver" : {
"node" : {
"extensions" : [
".js" ,
".jsx"
]
}
}
} Beachten Sie, dass dies von (und wahrscheinlich einer Teilmenge von) Einstellungen für import/resolver -Erweiterungen unterscheidet, die .json , .coffee usw. umfassen können, was immer noch in die no-unresolved Regel einfließt.
Außerdem werden die folgenden import/ignore diese Liste überschreiben.
import/ignore Eine Liste von Regex -Zeichenfolgen, die, wenn sie mit einem Pfad übereinstimmt, das Matching -Modul nicht meldet, wenn keine export gefunden werden. In der Praxis bedeutet dies, dass andere Regeln als no-unresolved Regeln berichten, in denen keine import mit (absoluten Dateisystem-) Pfaden mit diesem Muster übereinstimmen.
no-unresolved hat seine eigene ignore .
{
"settings" : {
"import/ignore" : [
".coffee$" , // fraught with parse errors
".(scss|less|css)$" , // can't parse unprocessed CSS modules, either
] ,
} ,
}import/core-modules Eine Reihe zusätzlicher Module, die als "Kern" -Module betrachtet werden sollen-Module, die als behoben angesehen werden sollten, aber keinen Weg im Dateisystem haben. Ihr Resolver definiert möglicherweise bereits einige davon (zum Beispiel kennt der Knoten Resolver über fs und path ), sodass Sie diese nicht neu definieren müssen.
Zum Beispiel enthält Elektron ein electron :
import 'electron' // without extra config, will be flagged as unresolved! Das wäre sonst ungelöst. Um dies zu vermeiden, können Sie electron als Kernmodul bereitstellen:
// .eslintrc
{
"settings" : {
"import/core-modules" : [ "electron" ] ,
} ,
} In Electron's speziellem Fall gibt es eine gemeinsam genutzte Konfiguration mit dem Namen electron , die dies für Sie angibt.
Der Beitrag weiterer gemeinsamer Konfigurationen für andere Plattformen ist willkommen!
import/external-module-folders Eine Reihe von Ordnern. Aufgelöste Module nur von diesen Ordnern werden als "extern" angesehen. Standardmäßig - ["node_modules"] . Dies ist sinnvoll, wenn Sie Ihren Pfad oder WebPack so konfiguriert haben, dass Sie Ihre internen Pfade unterschiedlich umgehen, und Module aus einigen Ordnern, z. B. bower_components oder jspm_modules , als "extern" in Betracht gezogen werden möchten.
Diese Option ist auch in einem Monorepo -Setup: Auflistung hier alle Verzeichnisse, die Monorepos Pakete enthalten, und sie werden als externe behandelt, unabhängig davon, welcher Resolver verwendet wird.
Wenn Sie yarn PNP als Paketmanager verwenden, fügen Sie den .yarn -Ordner hinzu, und alle Ihre installierten Abhängigkeiten werden als external anstelle von internal angesehen.
Jedes Element in diesem Array ist entweder der Name eines Ordners, sein Unterweg oder sein absolutes Präfix -Pfad:
jspm_modules passt zu jeder Datei oder /home/me/project/jspm_modules Ordner mit dem Namen jspm_modules oder mit einem direkten oder nicht-direkten übergeordneten übergeordneten jspm_modules , /home/me/project/jspm_modules/some-pkg/index.js .
packages/core enthält einen beliebigen Pfad, der diese beiden Segmente enthält, z. B. /home/me/project/packages/core/src/utils.js .
/home/me/project/packages stimmen nur Dateien und Verzeichnisse in diesem Verzeichnis und im Verzeichnis selbst überein.
Bitte beachten Sie, dass hier nicht unvollständige Namen erlaubt sind, sodass components nicht bower_components und packages/ui übereinstimmen packages/ui-utils nicht übereinstimmen (aber packages/ui/utils übereinstimmen).
import/parsersEine Karte von Parsers zu Datei -Erweiterungsarrays. Wenn eine Dateierweiterung übereinstimmt, benötigt und verwendet der Abhängigkeitsparser den Kartenschlüssel als Parser anstelle des konfigurierten Eslint -Parsers. Dies ist nützlich, wenn Sie mit dem WEBPACK direkt mit TypeScript mit dem OP-ing-inging: beispielsweise mit WebPack:
// .eslintrc
{
"settings" : {
"import/parsers" : {
"@typescript-eslint/parser" : [ ".ts" , ".tsx" ] ,
} ,
} ,
} In diesem Fall muss @typescript-eslint/parser aus dem Standort des laufenden eslint installiert und benötigt werden (dh es als Peer of ESlint installieren).
Dies wird derzeit nur mit @typescript-eslint/parser (und seinem Vorgänger, typescript-eslint-parser ) getestet, sollte jedoch theoretisch mit einem mäßig estreze-konformen Parser arbeiten.
Es ist schwer zu sagen, wie gut verschiedene Pluginfunktionen unterstützt werden, je nachdem, wie weit das Kaninchenloch unten geht. Senden Sie ein Problem ein, wenn Sie hier ein seltsames Verhalten darüber hinaus finden, aber Ihr Herz gegen das wahrscheinliche Ergebnis des Schließens mit wontfix .
import/resolverSiehe Resolver.
import/cache Einstellungen für das Cache -Verhalten. Memoisierung wird auf verschiedenen Ebenen verwendet, um die reichliche Menge an fs.statSync /modul -analyse -Aufrufen zu vermeiden, die erforderlich sind, um Fehler korrekt zu melden.
Für normale eslint -Konsole -Läufe ist die Lebensdauer der Cache -Lebensdauer irrelevant, da wir stark davon ausgehen können, dass sich Dateien im Laufe der Lebensdauer des Linterprozesses nicht ändern sollten (und damit der Cache im Speicher).
Für langlebige Prozesse wie eslint_d oder eslint-loader ist es jedoch wichtig, dass es einen Begriff der Staltigkeit gibt.
Wenn Sie nie eslint_d oder eslint-loader verwenden, können Sie die Lebensdauer der Cache auf Infinity festlegen, und alles sollte in Ordnung sein:
// .eslintrc
{
"settings" : {
"import/cache" : {
"lifetime" : "∞" , // or Infinity, in a JS config
} ,
} ,
}Andernfalls stellen Sie einige Ganzzahl fest, und Cache -Einträge werden nach so vielen Sekunden verstrichen:
// .eslintrc
{
"settings" : {
"import/cache" : {
"lifetime" : 5 , // 30 is the default
} ,
} ,
}import/internal-regexEin Regex für Pakete sollte als intern behandelt werden. Nützlich, wenn Sie ein Monorepo -Setup verwenden oder eine Reihe von Paketen entwickeln, die voneinander abhängen.
Standardmäßig wird jedes Paket, auf das aus import/external-module-folders verwiesen wird, als "extern" angesehen, einschließlich Paketen in einem Monorepo-wie Garn-Arbeitsbereich oder Lerna-Umgebung. Wenn Sie diese Pakete als "intern" markieren möchten, ist dies nützlich.
Wenn Ihre Pakete in einem Monorepo beispielsweise alle in @scope sind, können Sie import/internal-regex wie diese konfigurieren
// .eslintrc
{
"settings" : {
"import/internal-regex" : "^@scope/" ,
} ,
}import/node-versionEine Zeichenfolge, die die Version von Node.js darstellt, die Sie verwenden. Ein falsy -Wert impliziert die Version von node.js, mit denen Sie Eslint ausführen.
// .eslintrc
{
"settings" : {
"import/node-version" : "22.3.4" ,
} ,
} SublimelInter-ESLINT führte eine Änderung zur Unterstützung .eslintignore -Dateien ein, die die Art und Weise veränderten, wie Dateipfade beim Leinen während der Bearbeitung an Eslint übergeben werden. Diese Änderung sendet einen relativen Pfad anstelle des absoluten Pfades zur Datei (wie es normal liefert), was es diesem Plugin unmöglich machen kann, Abhängigkeiten im Dateisystem zu beheben.
Diese Problemumgehung sollte bei der Veröffentlichung von Eslint 2.0 nicht mehr erforderlich sein, wenn .eslintignore aktualisiert wird, um eher wie ein .gitignore zu funktionieren, was die ordnungsgemäße Ignorierung absoluter Pfade über --stdin-filename unterstützen sollte.
In der Zwischenzeit finden Sie in Roadhump/Sublimelinter-ESLINT#58 weitere Details und Diskussionen. Im Wesentlichen müssen Sie möglicherweise die folgende SublimeLinter Konfiguration zu Ihrer Sublime-Projektdatei hinzufügen:
{
"folders" :
[
{
"path" : " code "
}
],
"SublimeLinter" :
{
"linters" :
{
"eslint" :
{
"chdir" : " ${project}/code "
}
}
}
} Beachten Sie, dass ${project}/code mit dem code übereinstimmt, das in folders[0].path bereitgestellt wird.
Der Zweck der chdir Einstellung besteht in diesem Fall darin, das Arbeitsverzeichnis festzustellen, aus dem Eslint so ausgeführt wird, dass es dem Verzeichnis ist, auf dem Sublimelinter-E-Lint den relativen Pfad basiert, den es bietet.
Weitere Informationen finden Sie in den Sublimelinter -Dokumenten auf chdir , falls dies nicht mit Ihrem Projekt funktioniert.
Wenn Sie .eslintignore nicht verwenden oder keine erhebliche Projektdatei haben, können Sie auch über eine .sublimelinterrc -Datei in einem Vorfahren Ihres Codes Folgendes erstellen:
{
"linters" : {
"eslint" : {
"args" : [ " --stdin-filename " , " @ " ]
}
}
} Ich stellte auch fest, dass ich rc_search_limit auf null festlegen musste, wodurch das Suchgrenze der Dateihierarchie entfernt wird, wenn der Verzeichnisbaum für .sublimelinterrc nachgedacht wird:
In Paketeinstellungen / Sublimelinter / Benutzereinstellungen:
{
"user" : {
"rc_search_limit" : null
}
} Ich glaube, dass diese Standardeinstellungen auf 3 , sodass Sie dies möglicherweise nicht je nach maximaler Tiefe Ihres Projektordners ändern müssen.
