vscode eslint
release
Intègre Eslint dans le code vs. Si vous êtes nouveau dans Eslint, consultez la documentation.
L'extension utilise la bibliothèque Eslint installée dans le dossier d'espace de travail ouvert. Si le dossier n'en fournit pas un, l'extension recherche une version d'installation globale. Si vous n'avez pas installé Eslint, faites localement ou globalement, faites-le en exécutant npm install eslint dans le dossier Workspace pour une installation locale ou npm install -g eslint pour une installation globale.
Sur les nouveaux dossiers, vous devrez peut-être également créer un fichier de configuration .eslintrc . Vous pouvez le faire en utilisant la commande VS Code Create ESLint configuration ou en exécutant la commande eslint dans un terminal avec npx eslint --init .
Cette section décrit les grandes versions et leurs améliorations. Pour une liste détaillée de modifications, veuillez vous référer au journal de modification.
Depuis la version 2.2.3 sur les numéros de version Odd Minor ou Patch Forward Indiquez un initié ou un pré-libération. Ainsi, les versions 2.2.3 , 2.2.5 et 2.3.1 seront toutes des versions de pré-libération. 2.2.10 , 2.4.10 et 3.0.0 seront toutes des versions de libération régulières.
eslint.validate est spécifié, seuls les fichiers de cette liste seront validés. Par exemple, un réglage du formulaire "eslint.validate": [
"javascript"
]
eslint.useFlatConfig qui est honoré par Eslint version 8.57.0 et supérieur. Si l'une de ces versions est utilisée, l'extension adhère au plan de déploiement de configuration à plat Eslint. Le paramètre a la même signification que la variable d'environnement ESLINT_USE_FLAT_CONFIG . Cela signifie:eslint.experimental.useFlatConfig sont obsolètes et ne doivent être utilisés que pour les versions Eslint> = 8,21 <8.57.0.ESLint: Revalidate all open files pour revalider tous les fichiers ouverts.eslint.timeBudget.onValidation et eslint.timeBudget.onFixesuntitled agnostiqueeslint.alwaysShowStatus ont été supprimés car l'état est maintenant affiché comme un indicateur d'état du langage.eslint.timeBudget.onValidation et eslint.timeBudget.onFixesuntitled agnostiqueeslint.alwaysShowStatus ont été supprimés car l'état est maintenant affiché comme un indicateur d'état du langage. Ajout du support pour Eslint V8.0 Beta. Pour rester en arrière compatible avec les paramètres Eslint, la version utilise toujours le Cliengine si disponible. Cependant, les utilisateurs peuvent forcer l'utilisation de la nouvelle API Eslint à l'aide du paramètre eslint.useESLintClass . Méfiez-vous que le module NPM Eslint a changé la façon dont les options sont interprétées. Il a également changé les noms de certaines options. Si vous avez utilisé eslint.options pour transmettre des options spéciales au module NPM Eslint, vous devrez peut-être adapter le paramètre au nouveau formulaire.
Adaptez le modèle de confiance de l'espace de travail de Code. En conséquence, la boîte de dialogue personnalisée introduite dans la version 2.1.7 a été supprimée. En outre, la valeur off a été ajoutée au support de personnalisation des règles Eslint.
Ajout d'un soutien pour personnaliser la gravité des règles d'Eslint. Voir le nouveau paramètre eslint.rules.customizations .
Demander la confirmation de la valeur eslint.nodePath a révélé une configuration où cette valeur est définie séparément au niveau du dossier d'espace de travail bien qu'une configuration de dossier d'espace de travail multi-œuvres soit ouverte (par exemple, un fichier de code-workspace). Ces configurations doivent définir la valeur eslint.nodePath dans le fichier code-workspace correspondant et l'extension met désormais en garde l'utilisateur à ce sujet. Ci-dessous un exemple d'un tel fichier code-workspace
{
"folders" : [
{
"path" : " project-a "
},
{
"path" : " project-b "
}
],
"settings" : {
"eslint.nodePath" : " myCustomNodePath "
}
} Pour suivre le modèle de Code vs pour confirmer les paramètres locaux de l'espace de travail qui ont un impact sur l'exécution du code Les deux paramètres eslint.runtime et eslint.nodePath ont désormais besoin de confirmation de l'utilisateur s'il est défini localement dans un dossier d'espace de travail ou un fichier d'espace de travail. Les utilisateurs utilisant ces paramètres dans ces lunettes locales verront une notification leur rappelant le besoin de confirmation.
La version ajoute également une commande pour redémarrer le serveur Eslint.
Le flux d'approbation pour permettre l'exécution d'une bibliothèque Eslint a été retravaillé. Son expérience initiale est maintenant la suivante:
indiquant que l'exécution est actuellement bloquée.L'exécution de la bibliothèque Eslint peut être refusée ou approuvée à l'aide des gestes suivants:
ESLint: Manage Library Execution à partir de la palette de commandeTous les gestes ouvriront la boîte de dialogue suivante:
L'action choisie est ensuite reflétée dans l'élément de barre d'état Eslint de la manière suivante:
Allow la préfixe de la barre d'état avec une coche.Allow Everywhere préfixera l'élément de barre d'état avec un double coche.Deny et Disable préfixera l'élément de barre d'état avec un panneau bloqué.Vous pouvez gérer nos décisions en utilisant les commandes suivantes:
ESLint: Manage Library Execution rouvrira la boîte de dialogue ci-dessusESLint: Reset Library Decisions vous permet de réinitialiser les décisions précédentes qui ont pris.Cette version traite également de la vulnérabilité décrite dans CVE-2021-27081.
La version 2.0.4 de l'extension contient les principales améliorations suivantes:
eslint.validate de VS Code. Il en va de même pour les fichiers html et vue.js.eslint.workingDirectories peuvent désormais utiliser des modèles GLOB au lieu de répertorier chaque dossier de projet. Par exemple, { "pattern": "code-*" } correspondra à tous les dossiers de projet en commençant par code- . De plus, l'extension modifie désormais le répertoire de travail par défaut. Vous pouvez désactiver cette fonctionnalité avec la nouvelle propriété !cwd .eslint.format.enable .editor.codeActionsOnSave . Le paramètre prend en charge la propriété spécifique Eslint source.fixAll.eslint . L'extension respecte également la propriété générique source.fixAll .Le paramètre ci-dessous s'active sur le correctif automatique pour tous les fournisseurs, y compris Eslint:
"editor.codeActionsOnSave" : {
"source.fixAll" : " explicit "
}En revanche, cette configuration ne l'allume que pour Eslint:
"editor.codeActionsOnSave" : {
"source.fixAll.eslint" : " explicit "
}Vous pouvez également désactiver sélectivement Eslint via:
"editor.codeActionsOnSave" : {
"source.fixAll" : " explicit " ,
"source.fixAll.eslint" : " never "
} Notez également qu'il y a un budget de temps de 750 ms pour exécuter des actions de code sur SAVE, ce qui pourrait ne pas être suffisant pour un grand fichier JavaScript / TypeScript. Vous pouvez augmenter le budget de temps à l'aide du paramètre editor.codeActionsOnSaveTimeout .
L'ancien paramètre eslint.autoFixOnSave est désormais obsolète et peut être supprimé en toute sécurité.
Si vous utilisez une version d'extension Eslint <2.x, veuillez consulter les options de paramètres ici.
Cette extension contribue les variables suivantes aux paramètres:
eslint.enable : activer / désactiver Eslint pour le dossier de l'espace de travail. Est activé par défaut.
eslint.debug : Active le mode de débogage d'Eslint (Identique à l'option de la ligne de commande - debug). Veuillez consulter le canal de sortie Eslint pour la sortie de débogage. Ces options sont très utiles pour retrouver les problèmes de configuration et d'installation avec Eslint, car il fournit des informations verbales sur la façon dont Eslint valide un fichier.
eslint.lintTask.enable : si l'extension contribue à une tâche de peluche à un dossier entier d'un dossier d'espace de travail.
eslint.lintTask.options : Options de ligne de commande appliquées lors de l'exécution de la tâche pour lier tout l'espace de travail (https://eslint.org/docs/user-guide/command-line-interface). Un exemple pour pointer un fichier .eslintrc.json personnalisé et un .eslintignore personnalisé est:
{
"eslint.lintTask.options" : " -c C:/mydirectory/.eslintrc.json --ignore-path C:/mydirectory/.eslintignore . "
} L'ancien paramètre eslint.packageManager est désormais obsolète et peut être supprimé en toute sécurité. Cela contrôlait le gestionnaire de packages à utiliser pour résoudre la bibliothèque Eslint. Cela n'a qu'une influence si la bibliothèque Eslint est résolue à l'échelle mondiale. Les valeurs valides sont "npm" ou "yarn" ou "pnpm" .
eslint.options : Options pour configurer le démarrage d'Eslint à l'aide de l'API de classe Eslint ou de l'API Cliengine. L'extension utilise l'API de la classe Eslint si Eslint version 8 ou supérieure est utilisée ou si Eslint version 7 est utilisée et que le paramètre eslint.useESLintCLass est défini sur true. Dans tous les autres cas, l'API Clingine est utilisée. Un exemple pour pointer un fichier .eslintrc.json personnalisé à l'aide de la nouvelle API Eslint est:
{
"eslint.options" : { "overrideConfigFile" : " C:/mydirectory/.eslintrc.json " }
} Un exemple pour pointer un fichier .eslintrc.json personnalisé à l'aide de l'ancienne API Cliengine est:
{
"eslint.options" : { "configFile" : " C:/mydirectory/.eslintrc.json " }
} eslint.useESLintClass (@Since 2.2.0) - Il faut utiliser l'API de la classe Eslint même si l'API CliEngine est présente. Le paramètre n'est que l'honneur lors de l'utilisation d'Eslint version 7.x.
eslint.run - Exécutez le linter onSave ou onType , par défaut est onType .
eslint.quiet - ignorer les avertissements.
eslint.runtime - Utilisez ce paramètre pour définir le chemin du chemin du Node Runtime pour exécuter Eslint Under. Utilisez "node" si vous souhaitez utiliser votre version système par défaut du nœud.
eslint.execArgv - Utilisez ce paramètre pour transmettre des arguments supplémentaires à l'exécution du nœud comme --max_old_space_size=4096
eslint.nodeEnv - Utilisez ce paramètre si un plugin Eslint ou une configuration doit être défini process.env.NODE_ENV .
eslint.nodePath - Utilisez ce paramètre si un package Eslint installé ne peut pas être détecté, par exemple /myGlobalNodePackages/node_modules .
eslint.probe - Un tableau pour les identifiants linguistiques pour lesquels l'extension Eslint doit être activée et devrait essayer de valider le fichier. Si la validation échoue pour les langues sondées, l'extension dit silencieuse. Par défaut est ["astro", "javascript", "javascriptreact", "typescript","typescriptreact", "html", "mdx", "vue", "markdown", "json", "jsonc"] .
eslint.validate - Un tableau d'identificateurs de langage spécifiant les fichiers pour lesquels la validation doit être appliquée. S'il est spécifié, seuls les fichiers avec l'un des ID de langue spécifiés seront validés. Ceci est comparable à l'option de ligne de commande --ext . Par défaut est null .
eslint.format.enable : Active Eslint en tant que formateur pour les fichiers validés. Bien que vous puissiez également utiliser le formateur sur Enregistrer en utilisant le paramètre editor.formatOnSave il est recommandé d'utiliser la fonction editor.codeActionsOnSave car il permet une meilleure configurabilité.
eslint.workingDirectories - Spécifie comment les répertoires de travail que Eslint utilisent sont calculés. Eslint résout les fichiers de configuration (par exemple eslintrc , .eslintignore ) par rapport à un répertoire de travail, il est donc important de le configurer correctement. Si l'exécution d'Eslint dans le terminal vous oblige à modifier le répertoire de travail dans le terminal en un sous-dossier, il est généralement nécessaire de modifier ce paramètre. (Voir aussi les options de classe Eslint # CWD). Veuillez également garder à l'esprit que le fichier .eslintrc* est résolu en considérant les répertoires parents alors que le fichier .eslintignore n'est honoré que dans le répertoire de travail actuel. Les valeurs suivantes peuvent être utilisées:
[{ "mode": "location" }] (@Since 2.0.0): Demande à Eslint d'utiliser l'emplacement du dossier de l'espace de travail ou l'emplacement du fichier (si aucun dossier d'espace de travail n'est ouvert) comme répertoire de travail. Il s'agit de la valeur par défaut et est la même stratégie que celle utilisée dans les anciennes versions de l'extension Eslint (versions 1.9.x).[{ "mode": "auto" }] (@Since 2.0.0): Demande Eslint de déduire un répertoire de travail basé sur l'emplacement de package.json , eslint.config.js , .eslintignore et .eslintrc* . Cela peut fonctionner dans de nombreux cas, mais peut également conduire à des résultats inattendus.string[] : un tableau de répertoires de travail à utiliser. Considérez la disposition du répertoire suivant: root/
client/
.eslintrc.json
client.js
server/
.eslintignore
.eslintrc.json
server.js
"eslint.workingDirectories" : [ "./client" , "./server" ]!cwd peut être utilisé (par exemple { "directory": "./client", "!cwd": true } ). Cela utilisera le répertoire client comme répertoire de travail Eslint mais ne modifiera pas le répertoire de travail du processus.[{ "pattern": glob pattern }] (@Since 2.0.0): permet de spécifier un modèle pour détecter le répertoire de travail. Il s'agit essentiellement d'une raccourci pour répertorier chaque répertoire. Si vous avez un référentiel mono avec tous vos projets en dessous d'un dossier de packages, vous pouvez utiliser { "pattern": "./packages/*/" } pour faire de tous ces dossiers les répertoires de travail. eslint.codeAction.disableRuleComment - Objet avec propriétés:
enable - Afficher la règle de lunt désactiver dans le menu Fix rapide. true par défaut.location - Choisissez d'ajouter le commentaire eslint-disable sur la separateLine ou sameLine . separateLine est la valeur par défaut. Exemple: { "enable" : true , "location" : " sameLine " } eslint.codeAction.showDocumentation - Objet avec propriétés:
enable - Afficher la page Web de documentation Open Lint Rule dans le menu Fix rapide. true par défaut. eslint.codeActionsOnSave.mode (@SINC 2.0.12) - Contrôle quels problèmes sont résolus lors de l'exécution des actions de code sur SAVE.
all : résoudre tous les problèmes possibles en révalisant le contenu du fichier. Cela exécute le même chemin de code que l'exécution d'Eslint avec l'option --fix dans le terminal et peut donc prendre un certain temps. Ceci est la valeur par défaut.problems : Corrige uniquement les problèmes réparables actuellement connus tant que leurs modifications textuelles ne se chevauchent pas. Ce mode est beaucoup plus rapide mais fixe très probablement les parties des problèmes. Veuillez noter que si eslint.codeActionsOnSave.mode est défini sur problems , le eslint.codeActionsOnSave.rules est ignoré.
eslint.codeActionsOnSave.rules (@Since 2.2.0) - contrôle les règles qui sont prises en considération lors de l'action du code lors de l'exécution de sauvegarde. Si ce n'est pas spécifié, toutes les règles spécifiées via le mécanisme de configuration d'Eslint normal sont considérées. Un tableau vide ne se traduit par aucune règle envisagée. Si le tableau contient plus d'une entrée, l'ordre compte et le premier match détermine l'état ON / OFF de la règle. Ce cadre n'est honoré que dans les cas suivants:
eslint.codeActionsOnSave.mode a une valeur différente de celle problemseslint.useESLintClass est défini sur true (version> = 8 || (version == 7.x && eslint.UseeslintClass)).Dans cet exemple, seules les règles liées aux demi-finales sont prises en compte:
"eslint.codeActionsOnSave.rules" : [
" *semi* "
]Cet exemple supprime toutes les règles spécifiques de TypeScript Eslint de l'action de code sur Save Pass mais conserve toutes les autres règles:
"eslint.codeActionsOnSave.rules" : [
" !@typescript-eslint/* " ,
" * "
]Cet exemple maintient le retrait et la semi-règle de TypeScript Eslint, désactive toutes les autres règles Eslint TypeScript et conserve le reste:
"eslint.codeActionsOnSave.rules" : [
" @typescript-eslint/semi " ,
" @typescript-eslint/indent " ,
" !@typescript-eslint/* " ,
" * "
] eslint.rules.customizations (@Since 2.1.20) - Force les règles pour signaler une gravité différente dans le code vs par rapport à la configuration d'Eslint True Eslint du projet. Contient ces propriétés:
"rule ": Sélectionnez sur les règles avec des noms qui correspondent, en compte dans les astérisques comme Wildcards: { "rule": "no-*", "severity": "warn" }"!" Pour cibler toutes les règles qui ne correspondent pas au nom: { "rule": "!no-*", "severity": "info" }"severity" : définit une nouvelle gravité pour les règles appariées, "downgrade" à une gravité plus faible, "upgrade" à une gravité plus élevée, ou "default" à leur gravité d'origine"fixable" : Sélectionnez uniquement les règles autofixables: { "rule": "no-*", "fixable": true, "severity": "info" }Dans cet exemple, toutes les règles sont remplacées par les avertissements:
"eslint.rules.customizations" : [
{ "rule" : " * " , "severity" : " warn " }
] Dans cet exemple, no- règle n'est informative, d'autres règles sont rétrogradées et "radix" est réinitialisé à la valeur par défaut:
"eslint.rules.customizations" : [
{ "rule" : " no-* " , "severity" : " info " },
{ "rule" : " !no-* " , "severity" : " downgrade " },
{ "rule" : " radix " , "severity" : " default " }
]Dans cet exemple, toutes les règles autofixables sont remplacées par les informations:
"eslint.rules.customizations" : [
{ "rule" : " * " , "fixable" : true , "severity" : " info " }
] eslint.format.enable (@Since 2.0.0) - utilise Eslint comme format pour les fichiers validés par Eslint. Si vous êtes activé, assurez-vous de désactiver d'autres formateurs si vous souhaitez en faire la valeur par défaut. Une bonne façon de le faire est d'ajouter le paramètre suivant "[javascript]": { "editor.defaultFormatter": "dbaeumer.vscode-eslint" } pour JavaScript. Pour TypeScript, vous devez ajouter "[typescript]": { "editor.defaultFormatter": "dbaeumer.vscode-eslint" } .
eslint.onIgnoredFiles (@Since 2.0.10): utilisé pour contrôler si des avertissements doivent être générés lorsque vous essayez de peluchez des fichiers ignorés. La valeur par défaut est off . Peut être réglé pour warn .
editor.codeActionsOnSave (@Since 2.0.0): Ce paramètre prend désormais en charge une source.fixAll.eslint d'entrée.fixall.eslint. Si défini sur TRUE, toutes les erreurs Eslint fixables automatiquement de tous les plugins seront corrigées sur SAVE. Vous pouvez également activer et désactiver sélectivement les langages spécifiques à l'aide des paramètres étendus de la langue VS Code. Pour désactiver codeActionsOnSave pour les fichiers HTML, utilisez le paramètre suivant:
"[html]" : {
"editor.codeActionsOnSave" : {
"source.fixAll.eslint" : false
}
} L'ancien paramètre eslint.autoFixOnSave est désormais obsolète et peut être supprimé en toute sécurité. Veuillez également noter que si vous utilisez Eslint comme formateur par défaut, vous devez désactiver editor.formatOnSave lorsque vous avez activé editor.codeActionsOnSave . Sinon, votre fichier est corrigé deux fois, ce qui est inutile.
eslint.problems.shortenToSingleLine : (@Since 2.3.0) - raccourcit la portée du texte des problèmes soulignés à leur première ligne connexe.
eslint.experimental.useFlatConfig : (@Since 2.3.0) - Permet la prise en charge de la configuration plate expérimentale (aka eslint.config.js, prise en charge par Eslint version 8.21 ou ultérieure)
eslint.timeBudget.onValidation (@Since 2.3.5) - contrôle le budget de temps qui peut être utilisé pour la validation avant qu'un avertissement ou une erreur ne soit affiché.
eslint.timeBudget.onFixes (@Since 2.3.5) - contrôle le budget de temps qui peut être utilisé pour calculer les correctifs avant un avertissement ou une erreur.
Si l'ancienne option eslint.autoFixOnSave est définie sur True Eslint invitera à la convertir au format de nouveau editor.codeActionsOnSave . Si vous souhaitez éviter la migration, vous pouvez répondre dans la boîte de dialogue de la manière suivante:
off paramètre utilisateur eslint.migration.2_x La migration peut toujours être déclenchée manuellement à l'aide de la commande ESLint: Migrate Settings
Cette extension contribue les commandes suivantes à la palette de commandes.
Create '.eslintrc.json' file : Crée un nouveau fichier .eslintrc.json .Fix all auto-fixable problems : applique des résolutions de fixe automatique Eslint à tous les problèmes réparables. L'extension libelt un fichier individuel uniquement lors de la saisie. Si vous souhaitez pelucher l'ensemble de l'espace de travail set eslint.lintTask.enable to true et l'extension contribuera également la tâche eslint: lint whole folder . Il n'est plus nécessaire de définir une tâche personnalisée dans tasks.json .
Une excellente introduction sur la façon de dysporter de la peluche à l'aide d'Eslint peut être trouvée dans le type TypeScript - Eslint. Veuillez vous familiariser avec l'introduction avant d'utiliser l'extension VS Code Eslint dans une configuration TypeScript. Assurez-vous particulièrement que vous pouvez valider les fichiers TypeScript avec succès dans un terminal à l'aide de la commande eslint .
Ce projet lui-même utilise Eslint pour valider ses fichiers TypeScript. Il peut donc être utilisé comme un plan pour commencer.
Pour éviter la validation de toute installation Tslint, désactivez Tslint en utilisant "tslint.enable": false .
Comme pour JavaScript, validant TypeScript dans un référentiel mono, vous oblige à dire à l'extension VS Code Eslint quels sont les répertoires de travail actuels. Utilisez le paramètre eslint.workingDirectories pour le faire. Pour ce référentiel, la configuration du répertoire de travail ressemble comme suit:
"eslint.workingDirectories" : [ " ./client " , " ./server " ]La migration de Eslint 5.x vers Eslint 6.x pourrait nécessiter une certaine adaptation (voir le guide de migration Eslint pour plus de détails). Avant de déposer un problème par rapport à l'extension Eslint du code VS, veuillez vous assurer que vous pouvez valider avec succès vos fichiers dans un terminal à l'aide de la commande Eslint.
