eslint plugin import
v2.31.0
Ce plugin a l'intention de prendre en charge la liaison de la syntaxe d'importation ES2015 + (ES6 +) et d'éviter les problèmes avec mal orthographié des chemins de fichier et des noms d'importation. Toute la bonté que la syntaxe du module statique ES2015 + a l'intention de fournir, marquée dans votre éditeur.
Si vous utilisez cela avec Sublime : Voir la section inférieure pour des informations importantes.
Configurations activées dans.
Configurations désactivées dans.
❗ Définissez la configuration errors .
☑️ Définissez la configuration recommended .
⌨️ Définissez dans la configuration typescript .
? Définir la configuration warnings .
? Automatiquement réparable par l'option --fix CLI.
Manuellement réparable par les suggestions des éditeurs.
Déprécié.
| Nom | Description | ? | |||||
|---|---|---|---|---|---|---|---|
| exporter | Interdire toute exportation non valide, c'est-à-dire réexporter du même nom. | ❗ ☑️ | |||||
| sans dépréciation | Interdire les noms importés marqués de la balise de documentation @deprecated . | ||||||
| Blocs sans vide | Interdire vide nommé les blocs d'importation. | ? | |||||
| les dépendances non extranées | Interdire l'utilisation de packages étrangers. | ||||||
| Exports sans mutable | Interdire l'utilisation d'exportations mutables avec var ou let . | ||||||
| Non-nom | Interdire l'utilisation du nom exporté comme identifiant de l'exportation par défaut. | ☑️? | |||||
| membre du membre du nom | Interdire l'utilisation du nom exporté comme propriété de l'exportation par défaut. | ☑️? | |||||
| modules sans undis | Interdire les modules sans exportations ou exportations sans faire correspondre l'importation dans un autre module. |
| Nom | Description | ? | |||||
|---|---|---|---|---|---|---|---|
| sans AMD | Interdire que l'AMD require et define les appels. | ||||||
| pas de commun | Interdire CommonJS require les appels et module.exports ou exports.* . | ||||||
| Exports de module sans importance | Interdire les déclarations d'importation avec CommonJS module.exports. | ? | |||||
| modules sans nodejs | Interdire les modules nœuds.js intégrés. | ||||||
| non ambigu | Interdire l'objectif d'analyse potentiellement ambigu ( script vs module ). |
| Nom | Description | ? | |||||
|---|---|---|---|---|---|---|---|
| défaut | Assurez-vous qu'une exportation par défaut est présente, compte tenu d'une importation par défaut. | ❗ ☑️ | |||||
| appliquer un usage-protocol-usage | Appliquer en utilisant ou en omettant le node: Protocole lors de l'importation de modules node.js intégrés. | ? | |||||
| nommé | Assurez-vous que les importations nommées correspondent à une exportation nommée dans le fichier distant. | ❗ ☑️ | ⌨️ | ||||
| espace de noms | Assurez-vous que les espaces de noms importés contiennent des propriétés déréférencées car elles sont désérigées. | ❗ ☑️ | |||||
| pas de chemin de non-absolu | Interdire l'importation de modules à l'aide de chemins absolus. | ? | |||||
| sans cycle | Interdire à un module d'importer un module avec un chemin de dépendance vers lui-même. | ||||||
| sans dynamique | Interdire require() appels avec des expressions. | ||||||
| pas de modules internes | Interdire l'importation des sous-modules d'autres modules. | ||||||
| sans rapport relative | Interdire l'importation de packages par des chemins relatifs. | ? | |||||
| sans rapport-importance | Interdire l'importation de modules des répertoires parents. | ||||||
| Paths sans restriction | Appliquer quels fichiers peuvent être importés dans un dossier donné. | ||||||
| pas d'importance | Interdire à un module d'importer lui-même. | ||||||
| sans résolution | Assurez-vous que les importations pointent vers un fichier / module qui peut être résolu. | ❗ ☑️ | |||||
| sans segments sans path | Interdire les segments de chemin inutiles dans l'importation et nécessitent des déclarations. | ? | |||||
| no-webpack-chargedeur-syntax | Interdire la syntaxe de chargeur Webpack dans les importations. |
| Nom | Description | ? | |||||
|---|---|---|---|---|---|---|---|
| de style spécialiste de type cohérent | Appliquer ou interdire l'utilisation de marqueurs en ligne uniquement pour les importations nommées. | ? | |||||
| nom-chunkname dynamique | Appliquez un commentaire leader avec le webPackChunkName pour les importations dynamiques. | ||||||
| exportations-allonges | Assurez-vous que toutes les exportations apparaissent après d'autres déclarations. | ||||||
| extensions | Assurez-vous une utilisation cohérente de l'extension de fichier dans le chemin d'importation. | ||||||
| d'abord | Assurez-vous que toutes les importations apparaissent avant d'autres déclarations. | ? | |||||
| Exports de groupe | Préférez les exportations nommées à être regroupées dans une seule déclaration d'exportation | ||||||
| importations d'abord | Remplacé par import/first . | ? | |||||
| dépendances maximales | Appliquer le nombre maximal de dépendances qu'un module peut avoir. | ||||||
| Newline-après-importation | Appliquer une nouvelle ligne après les instructions d'importation. | ? | |||||
| no-anonymous-défaut-export | Interdire les valeurs anonymes comme exportations par défaut. | ||||||
| sans défaut | Interdire les exportations par défaut. | ||||||
| pas de duplicité | Interdire l'importation répétée du même module à plusieurs endroits. | ☑️? | ? | ||||
| sans défaut | Interdire les exportations par défaut nommées. | ||||||
| non nommé | Interdire les exportations nommées. | ||||||
| Espace sans noms | Image des imports de noms de noms (aka "Wildcard" * ). | ? | |||||
| Importation sans prédication | Interdire les importations non attribuées | ||||||
| commande | Appliquer une convention dans l'ordre d'importation des modules. | ? | |||||
| préférer-défaut-export | Préférez une exportation par défaut si le module exporte un seul nom ou plusieurs noms. |
eslint-plugin-import pour l'entrepriseDisponible dans le cadre de l'abonnement Tidelift.
Les responsables d' eslint-plugin-import et des milliers d'autres packages travaillent avec Tidelift pour fournir un support commercial et une maintenance pour les dépendances open source que vous utilisez pour créer vos applications. Économisez du temps, réduisez les risques et améliorez la santé du code, tout en payant les maintenseurs des dépendances exactes que vous utilisez. Apprendre encore plus.
# inside your project's working tree
npm install eslint-plugin-import --save-dev.eslintrc ) Toutes les règles sont désactivées par défaut. Cependant, vous pouvez étendre l'une des configurations prédéfinies ou les configurer manuellement dans votre .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...
} ,
} ,eslint.config.js ) Toutes les règles sont désactivées par défaut. Cependant, vous pouvez les configurer manuellement dans votre eslint.config.(js|cjs|mjs) , ou étendre l'une des configurations prédéfinies:
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' ,
} ,
} ,
] ; Vous pouvez utiliser l'extrait suivant ou assembler votre propre configuration en utilisant les paramètres granulaires décrits en dessous.
Assurez-vous que vous avez installé @typescript-eslint/parser et eslint-import-resolver-typescript qui sont utilisés dans la configuration suivante.
{
"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() dans typescript-eslint Si vous utilisez la méthode config à partir de typescript-eslint , assurez-vous que le flatConfig est inclus dans le tableau 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...
}
) ; Avec l'avènement des bundlers de modules et l'état actuel des modules et des spécifications de syntaxe des modules, il n'est pas toujours évident où import x from 'module' devrait chercher à trouver le fichier derrière module .
Grâce à V0.10ish, ce plugin a utilisé directement le plugin resolve de Subdack, qui met en œuvre le comportement d'importation de Node. Cela fonctionne assez bien dans la plupart des cas.
Cependant, WebPack permet un certain nombre de choses dans les chaînes de source du module d'importation que le nœud ne fait pas, comme les chargeurs ( import 'file!./whatever' ) et un certain nombre de schémas d'aliasing, tels que externals : mappage d'un ID de module à un nom global à l'exécution (permettant à certains modules d'être inclus plus traditionnellement via des étiquettes de script).
Dans l'intérêt de soutenir les deux, V0.11 présente des résolveurs.
Actuellement, la résolution de nœuds et de webpack a été mise en œuvre, mais les résolveurs ne sont que des packages NPM, de sorte que les forfaits tiers sont pris en charge (et encouragés!).
Vous pouvez référencer les résolveurs de plusieurs manières (par ordre de priorité):
eslint-import-resolver , comme 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 }
}
}
} Les chemins relatifs seront résolus par rapport au package.json le plus proche de la source.json ou au répertoire de travail actuel du processus si aucun package.json n'est trouvé.
Si vous êtes intéressant en écrivant un résolveur, consultez la spécification pour plus de détails.
Vous pouvez définir les paramètres suivants dans votre .eslintrc :
import/extensions Une liste des extensions de fichiers qui seront analysées sous forme de modules et inspectées pour export .
Cela par défaut ['.js'] , sauf si vous utilisez la configuration partagée react , auquel cas il est spécifié comme ['.js', '.jsx'] . Malgré la valeur par défaut, si vous utilisez TypeScript (sans le plugin:import/typescript Config décrit ci-dessus), vous devez spécifier les nouvelles extensions ( .ts , et aussi .tsx si vous utilisez React).
"settings" : {
"import/extensions" : [
".js" ,
".jsx"
]
}Si vous avez besoin de définitions d'extensions granulaires, vous pouvez utiliser:
"settings" : {
"import/resolver" : {
"node" : {
"extensions" : [
".js" ,
".jsx"
]
}
}
} Notez que cela est différent (et probablement un sous-ensemble de) tous les paramètres d'extensions d' import/resolver , qui peuvent inclure .json , .coffee , etc. qui tiendra toujours en compte dans la règle no-unresolved .
De plus, les modèles import/ignore suivants annuleront cette liste.
import/ignore Une liste des chaînes Regex qui, si elles sont appariées par un chemin, ne rapporteront pas le module de correspondance si aucune export n'est trouvée. Dans la pratique, cela signifie que des règles autres que no-unresolved ne rapporteront aucune import avec des chemins (système de fichiers absolus) correspondant à ce modèle.
no-unresolved a son propre paramètre ignore .
{
"settings" : {
"import/ignore" : [
".coffee$" , // fraught with parse errors
".(scss|less|css)$" , // can't parse unprocessed CSS modules, either
] ,
} ,
}import/core-modules Un tableau de modules supplémentaires à considérer comme des modules "de base" - des modules qui doivent être considérés comme résolus mais n'ont pas de chemin sur le système de fichiers. Votre résolveur peut déjà définir certains d'entre eux (par exemple, le Node Resolver connaît fs et path ), vous n'avez donc pas besoin de les redéfinir.
Par exemple, Electron expose un module electron :
import 'electron' // without extra config, will be flagged as unresolved! Ce serait autrement non résolu. Pour éviter cela, vous pouvez fournir electron comme module de base:
// .eslintrc
{
"settings" : {
"import/core-modules" : [ "electron" ] ,
} ,
} Dans le cas spécifique d'Electron, il existe une configuration partagée nommée electron qui le spécifie pour vous.
La contribution de plus de configurations partagées pour d'autres plates-formes est la bienvenue!
import/external-module-folders Un tableau de dossiers. Les modules résolus uniquement à partir de ces dossiers seront considérés comme "externes". Par défaut - ["node_modules"] . Il est logique que vous ayez configuré votre chemin ou WebPack pour gérer vos chemins internes différemment et que vous souhaitez considérer les modules de certains dossiers, par exemple bower_components ou jspm_modules , comme "externe".
Cette option est également utile dans une configuration MonorePo: Liste ici tous les répertoires contenant des packages de Monorepo et ils seront traités comme externes, quel que soit le résolveur utilisé.
Si vous utilisez le PNP yarn comme gestionnaire de packages, ajoutez le dossier .yarn et toutes vos dépendances installées seront considérées comme external , au lieu d' internal .
Chaque élément de ce tableau est soit le nom d'un dossier, son sous-chemin, soit son chemin de préfixe absolu:
jspm_modules correspondra à tout fichier ou dossier nommé jspm_modules ou qui a un parent direct ou non direct nommé jspm_modules , eg /home/me/project/jspm_modules ou /home/me/project/jspm_modules/some-pkg/index.js .
packages/core correspondra à tout chemin qui contient ces deux segments, par exemple /home/me/project/packages/core/src/utils.js .
/home/me/project/packages ne correspondra que des fichiers et des répertoires à l'intérieur de ce répertoire, et le répertoire lui-même.
Veuillez noter que les noms incomplets ne sont pas autorisés ici, donc components ne correspondent pas bower_components et packages/ui ne correspondent pas packages/ui-utils (mais correspondra packages/ui/utils ).
import/parsersUne carte des analyseurs vers des tableaux d'extension de fichiers. Si une extension de fichier est adaptée, l'analyseur de dépendance nécessitera et utilisera la touche MAP comme analyseur au lieu de l'analyseur Eslint configuré. Ceci est utile si vous êtes interoppulé avec TypeScript directement à l'aide de WebPack, par exemple:
// .eslintrc
{
"settings" : {
"import/parsers" : {
"@typescript-eslint/parser" : [ ".ts" , ".tsx" ] ,
} ,
} ,
} Dans ce cas, @typescript-eslint/parser doit être installé et requis à partir de l'emplacement du module eslint en cours d'exécution (c'est-à-dire l'installer comme pair d'Eslint).
Ceci n'est actuellement testé qu'avec @typescript-eslint/parser (et son prédécesseur, typescript-eslint-parser ), mais devrait théoriquement fonctionner avec n'importe quel analyseur compatible modérément est-il.
Il est difficile de dire à quel point diverses fonctionnalités de plugin seront également prises en charge, selon la distance dans le niveau du terrier du lapin. Soumettez un problème si vous trouvez un comportement étrange au-delà ici, mais acquez votre cœur contre le résultat probable de la fermeture avec wontfix .
import/resolverVoir Resolvers.
import/cache Paramètres du comportement du cache. La mémorisation est utilisée à différents niveaux pour éviter la quantité abondante d'appels d'analyse fs.statSync / Module requis pour signaler correctement les erreurs.
Pour la console eslint normale, la durée de vie du cache n'est pas pertinente, car nous pouvons fortement supposer que les fichiers ne devraient pas changer pendant la durée de vie du processus de linter (et donc le cache en mémoire)
Pour les processus durables, comme eslint_d ou eslint-loader , il est important qu'il y ait une notion de stalesse.
Si vous n'utilisez jamais eslint_d ou eslint-loader , vous pouvez définir la durée de vie du cache sur Infinity et tout devrait être bien:
// .eslintrc
{
"settings" : {
"import/cache" : {
"lifetime" : "∞" , // or Infinity, in a JS config
} ,
} ,
}Sinon, définissez des entiers et les entrées de cache seront expulsées après que de nombreuses secondes se sont écoulées:
// .eslintrc
{
"settings" : {
"import/cache" : {
"lifetime" : 5 , // 30 is the default
} ,
} ,
}import/internal-regexUn exploitement pour les colis doit être traité comme interne. Utile lorsque vous utilisez une configuration monorepo ou en développant un ensemble de packages qui dépendent les uns des autres.
Par défaut, tout package référencé à partir import/external-module-folders sera considéré comme "externe", y compris des packages dans un espace de travail de Yarn ou un environnement Lerna monorepo. Si vous souhaitez marquer ces packages comme "internes", ce sera utile.
Par exemple, si vos packages dans un monorepo sont tous dans @scope , vous pouvez configurer import/internal-regex comme celui-ci
// .eslintrc
{
"settings" : {
"import/internal-regex" : "^@scope/" ,
} ,
}import/node-versionUne chaîne qui représente la version de Node.js que vous utilisez. Une valeur Falsy impliquera la version de Node.js avec laquelle vous exécutez Eslint.
// .eslintrc
{
"settings" : {
"import/node-version" : "22.3.4" ,
} ,
} SublimeLinter-Eslint a introduit une modification pour prendre en charge les fichiers .eslintignore qui ont modifié la façon dont les chemins de fichier sont passés à Eslint lors de la libellur lors de l'édition. Cette modification envoie un chemin relatif au lieu du chemin absolu du fichier (comme Eslint est normalement le fournit), ce qui peut empêcher ce plugin de résoudre les dépendances sur le système de fichiers.
Cette solution de contournement ne doit plus être nécessaire avec la publication d'Eslint 2.0, lorsque .eslintignore sera mis à jour pour fonctionner davantage comme un .gitignore , ce qui devrait prendre en charge l'ignorance appropriée des chemins absolus via --stdin-filename .
En attendant, voir Roadhump / Sublimelinter-Eslint # 58 pour plus de détails et de discussion, mais essentiellement, vous pouvez trouver que vous devez ajouter la configuration SublimeLinter suivante à votre fichier de projet sublime:
{
"folders" :
[
{
"path" : " code "
}
],
"SublimeLinter" :
{
"linters" :
{
"eslint" :
{
"chdir" : " ${project}/code "
}
}
}
} Notez que ${project}/code correspond au code fourni aux folders[0].path .
Le paramètre chdir , dans ce cas, est de définir le répertoire de travail à partir duquel Eslint est exécuté comme étant le même que le répertoire sur lequel Sublimelinter-Eslint fonde le chemin relatif qu'il fournit.
Consultez les documents Sublimelinter sur chdir pour plus d'informations, au cas où cela ne fonctionnerait pas avec votre projet.
Si vous n'utilisez pas .eslintignore ou que vous n'avez pas de fichier de projet sublime, vous pouvez également effectuer ce qui suit via un fichier .sublimelinterrc dans un répertoire ancêtre de votre code:
{
"linters" : {
"eslint" : {
"args" : [ " --stdin-filename " , " @ " ]
}
}
} J'ai également constaté que je devais définir rc_search_limit sur null , ce qui supprime la limite de recherche de la hiérarchie des fichiers lorsque vous recherchez l'arborescence du répertoire pour .sublimelinterrc :
Dans Paramètres de package / SUBIMELINTER / Paramètres utilisateur:
{
"user" : {
"rc_search_limit" : null
}
} Je crois que cela par défaut 3 , vous n'aurez peut-être pas besoin de le modifier en fonction de la profondeur maximale de votre dossier de projet.
