eslint config prettier
1.0.0
Désactive toutes les règles inutiles ou susceptibles d'entrer en conflit avec Prettier.
Cela vous permet d'utiliser votre configuration partageable préférée sans laisser ses choix stylistiques vous gêner lorsque vous utilisez Prettier.
Notez que cette configuration désactive uniquement les règles , il est donc logique de l'utiliser avec une autre configuration.
Installez eslint-config-prettier :
npm install --save-dev eslint-config-prettier
Ajoutez eslint-config-prettier à votre configuration ESLint – soit à eslintrc, soit à eslint.config.js (configuration plate).
eslintrc : ajoutez "prettier" au tableau "extends" dans votre fichier .eslintrc.* . Assurez-vous de le mettre en dernier afin qu'il ait la possibilité de remplacer les autres configurations.
{
"extends" : [
" some-other-config-you-use " ,
" prettier "
]
}eslint.config.js (configuration plate) : importez eslint-config-prettier et placez-le dans le tableau de configuration – après les autres configurations que vous souhaitez remplacer.
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
eslintConfigPrettier ,
] ; Enfin, exécutez l'outil d'assistance CLI pour rechercher des problèmes dans les sections "rules" de votre configuration.
Vous utilisez eslint-plugin-prettier ? Consultez la configuration recommandée par eslint-plugin-prettier.
eslint-config-prettier désactive non seulement les règles de base , mais également certaines de ces plugins automatiquement :
Remarque : Vous trouverez peut-être des guides sur Internet indiquant que vous devez également étendre des éléments tels que
"prettier/react". Depuis la version 8.0.0 d'eslint-config-prettier, il suffit d'étendre"prettier"! Cela inclut tous les plugins.
Avec une configuration plate, vous décidez du nom du plugin ! Par exemple:
import typescriptEslint from "@typescript-eslint/eslint-plugin" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
{
plugins : {
// You’d typically use one of the following two:
// typescriptEslint: typescriptEslint,
// typescriptEslint,
// But in this example we give it another name.
// It might be tempting to use something shorter like “ts”:
ts : typescriptEslint , // Don’t do this!
} ,
rules : {
// With eslintrc, this is _always_ called:
// @typescript-eslint/indent
// But in eslint.config.js (flat config), the name chosen above in `plugins` is used.
"ts/indent" : "error" , // Don’t do this!
} ,
} ,
eslintConfigPrettier ,
] ; Vous pourriez vous attendre à ce que eslint-config-prettier désactive ts/indent , mais ce ne sera pas le cas ! Parce que eslint-config-prettier désactive uniquement @typescript-eslint/indent . Il ne peut pas savoir comment vous avez choisi d’appeler le plugin. Même chose pour l'outil d'assistance CLI.
Tenez-vous-en simplement aux noms officiels des plugins et tout ira bien.
Si vous rencontrez une configuration partagée qui utilise un nom de plugin non standard, veuillez leur demander d'utiliser le nom standard à la place.
Certaines des règles désactivées par eslint-config-prettier peuvent être obsolètes, voire supprimées d'ESLint. C'est parfaitement bien, mais si vous avez vraiment besoin d'omettre les règles obsolètes et supprimées, vous pouvez le faire en définissant la variable d'environnement ESLINT_CONFIG_PRETTIER_NO_DEPRECATED sur une valeur non vide. Par exemple:
env ESLINT_CONFIG_PRETTIER_NO_DEPRECATED=true npx eslint-find-rules --deprecated index.js
eslint-config-prettier est également livré avec un petit outil CLI pour vous aider à vérifier si votre configuration contient des règles inutiles ou en conflit avec Prettier. Voici comment l'exécuter :
npx eslint-config-prettier path/to/main.js
(Remplacez path/to/main.js par un fichier qui existe dans votre projet.)
Voyons maintenant ce qu'il fait et pourquoi vous pourriez vouloir l'utiliser.
Cet exemple eslintrc a une règle de conflit "indent" activée :
{
"extends" : [
" some-other-config-you-use " ,
" prettier "
],
"rules" : {
"indent" : " error "
}
} Pour eslintrc, alors que la configuration "prettier" peut désactiver les règles problématiques dans "some-other-config-you-use" , elle ne peut pas toucher "rules" ! (C'est ainsi que fonctionne ESLint : il vous permet de remplacer les configurations que vous étendez.) L'outil d'assistance CLI signale que "indent" est en conflit avec Prettier, vous pouvez donc le supprimer. (Ce qui est bien : simplifier votre configuration !)
Cet exemple eslint.config.js (configuration plate) a également une règle de conflit "indent" activée :
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
eslintConfigPrettier ,
{
rules : {
indent : "error" ,
} ,
} ,
] ;Avec le nouveau format ESLint « configuration plate », vous pouvez contrôler vous-même quelles choses remplacent quoi. Une façon de résoudre le conflit ci-dessus consiste à réorganiser les objets de configuration afin que eslint-config-prettier soit le dernier :
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
{
rules : {
indent : "error" ,
} ,
} ,
eslintConfigPrettier , // eslint-config-prettier last
] ; Cependant, regarder la configuration ci-dessus peut sembler déroutant. Il semble que nous activions la règle indent , mais en réalité elle est désactivée grâce à la ligne eslintConfigPrettier en dessous. Au lieu de cela, vous souhaiterez peut-être avoir vos propres règles après eslint-config-prettier et exécuter l'outil d'assistance CLI pour découvrir les problèmes, afin de pouvoir supprimer complètement les règles conflictuelles du fichier de configuration (simplifiant votre configuration).
En théorie, vous devez exécuter l'outil pour chaque fichier de votre projet pour être sûr à 100 % qu'il n'y a pas de règles conflictuelles, car ESLint prend en charge des règles différentes pour différents fichiers. Habituellement, vous aurez à peu près les mêmes règles pour tous les fichiers, il suffit donc d'exécuter la commande sur un seul fichier. Mais si vous utilisez plusieurs fichiers de configuration ou remplacements, vous pouvez fournir plusieurs fichiers à vérifier :
npx eslint-config-prettier index.js test/index.js legacy/main.js
Tout comme ESLint lui-même, vous pouvez contrôler l'outil d'assistance CLI eslint-config-prettier à l'aide de la variable d'environnement ESLINT_USE_FLAT_CONFIG :
ESLINT_USE_FLAT_CONFIG=true : utilisez uniquement eslint.config.js (configuration plate).ESLINT_USE_FLAT_CONFIG=false : Utilisez uniquement les fichiers eslintrc.Avertissement
Pour eslint.config.js (configuration plate), l'outil d'assistance CLI importeeslint/use-at-your-own-riskqui peut se briser à tout moment.
Les versions eslint-config-prettier antérieures à 7.0.0 avaient un outil CLI légèrement différent qui était exécuté d'une manière différente. Par exemple:
npx eslint --print-config index.js | npx eslint-config-prettier-check
Si vous trouvez quelque chose comme ça dans un didacticiel, voici à quoi ressemble la commande dans la version 7.0.0 ou ultérieure :
npx eslint-config-prettier index.js
Il existe quelques règles désactivées par eslint-config-prettier qui peuvent en fait être activées dans certains cas.
--fix . Pour une facilité d'utilisation maximale, les règles spéciales sont désactivées par défaut (à condition que vous incluiez toutes les choses nécessaires dans "extends" ). Si vous les souhaitez, vous devez les spécifier explicitement dans votre configuration ESLint.
Ces règles peuvent causer des problèmes si vous utilisez eslint-plugin-prettier et --fix .
Voir le problème arrow-body-style et prefer-arrow-callback pour plus de détails.
Il existe plusieurs manières de désactiver ces règles :
"plugin:prettier/recommended" dans votre "extends" . C'est la configuration recommandée par eslint- plugin- prettier."prettier/prettier" dans votre "extends" . (Oui, il existe à la fois une règle appelée "prettier/prettier" et une configuration appelée "prettier/prettier" .) Peu importe l'approche que vous utilisez. "plugin:prettier/recommended" est probablement le plus simple.
Remarque : L'outil CLI ne les signale comme problématiques que si la règle "prettier/prettier" est activée pour le même fichier.
Ces règles peuvent être utilisées en toute sécurité si vous n'utilisez pas eslint-plugin-prettier. En d'autres termes, si vous exécutez eslint --fix et prettier --write en étapes distinctes.
Cette règle nécessite certaines options.
Si un bloc (par exemple after if , else , for ou while ) ne contient qu'une seule instruction, JavaScript permet d'omettre les accolades autour de cette instruction. Cette règle s'applique si ou quand ces accolades facultatives doivent être omises.
Si vous utilisez l'option "multi-line" ou "multi-or-nest" , la règle peut entrer en conflit avec Prettier.
Par exemple, l'option "multi-line" autorise cette ligne :
if ( cart . items && cart . items [ 0 ] && cart . items [ 0 ] . quantity === 0 ) updateCart ( cart ) ; Cependant, Prettier pourrait considérer la ligne trop longue et la transformer comme suit, ce que l'option "multi-line" ne permet pas :
if ( cart . items && cart . items [ 0 ] && cart . items [ 0 ] . quantity === 0 )
updateCart ( cart ) ; Si vous aimez cette règle, elle peut très bien être utilisée avec Prettier tant que vous n'utilisez pas l'option "multi-line" ou "multi-or-nest" .
Exemple de configuration ESLint :
{
"rules" : {
"curly" : [ " error " , " all " ]
}
}(Ce qui suit s'applique également à @typescript-eslint/lines-around-comment.)
Cette règle peut être utilisée avec certaines options.
Cette règle nécessite des lignes vides avant et/ou après les commentaires. Prettier préserve les lignes vides, à deux exceptions près :
Par défaut, ESLint nécessite une ligne vide au-dessus du commentaire dans ce cas :
if ( result ) {
/* comment */
return result ;
}Cependant, Prettier supprime la ligne vide :
if ( result ) {
/* comment */
return result ;
}Si vous aimez cette règle, elle peut très bien être utilisée avec Prettier à condition d'ajouter une configuration supplémentaire pour autoriser les commentaires au début et à la fin des blocs, des objets et des tableaux.
Exemple de configuration ESLint :
{
"rules" : {
"lines-around-comment" : [
" error " ,
{
"beforeBlockComment" : true ,
"afterBlockComment" : true ,
"beforeLineComment" : true ,
"afterLineComment" : true ,
"allowBlockStart" : true ,
"allowBlockEnd" : true ,
"allowObjectStart" : true ,
"allowObjectEnd" : true ,
"allowArrayStart" : true ,
"allowArrayEnd" : true
}
]
}
}(Ce qui suit s'applique également à vue/max-len.)
Cette règle nécessite une attention particulière lors de l’écriture du code.
Habituellement, Prettier se charge automatiquement de suivre une longueur de ligne maximale. Cependant, il existe des cas où Prettier ne peut rien faire, comme pour les longues chaînes, les expressions régulières et les commentaires. Ceux-ci doivent être divisés par un humain.
Si vous souhaitez appliquer une politique de longueur de ligne maximale encore plus stricte que celle que Prettier peut fournir automatiquement, vous pouvez activer cette règle. N'oubliez pas de synchroniser les options de max-len et l'option printWidth de Prettier.
Gardez à l'esprit que vous devrez peut-être refactoriser légèrement le code si Prettier formate les lignes d'une manière que la règle max-len n'approuve pas.
Exemple de configuration ESLint :
{
"rules" : {
"max-len" : [ " error " , { "code" : 80 , "ignoreUrls" : true }]
}
}Cette règle nécessite certaines options.
Par exemple, la règle pourrait avertir à propos de cette ligne :
var x = a => 1 ? 2 : 3 ; Avec {allowParens: true} (valeur par défaut depuis ESLint 6.0.0), l'ajout de parenthèses est considéré comme un moyen valable d'éviter la confusion des flèches :
var x = a => ( 1 ? 2 : 3 ) ;Bien que Prettier conserve ces parenthèses, il les supprime si la ligne est suffisamment longue pour introduire un saut de ligne :
EnterpriseCalculator . prototype . calculateImportantNumbers = inputNumber =>
1 ? 2 : 3 ; Avec {allowParens: false} , ESLint suggère plutôt de passer à un retour explicite :
var x = a => { return 1 ? 2 : 3 ; } ;Cela ne pose aucun problème avec Prettier.
Si vous aimez cette règle, elle peut très bien être utilisée avec Prettier tant que l'option allowParens est désactivée.
Exemple de configuration ESLint :
{
"rules" : {
"no-confusing-arrow" : [ " error " , { "allowParens" : false }]
}
} (Remarque : l'outil d'assistance CLI considère {allowParens: true} comme la valeur par défaut, ce qui est le cas depuis ESLint 6.0.0. L'outil produira un avertissement si vous utilisez la valeur par défaut, même si vous utilisez une ancienne version d'ESLint. Il ne fait pas de mal de définir explicitement {allowParens: false} même s'il est techniquement redondant. De cette façon, vous êtes prêt pour une future mise à niveau d'ESLint et l'outil CLI peut rester simple.)
Cette règle nécessite une attention particulière lors de l’écriture du code.
Cette règle interdit de mélanger certains opérateurs, comme && et || .
Par exemple, la règle pourrait avertir à propos de cette ligne :
var foo = a + b * c ;La règle suggère d'ajouter des parenthèses, comme ceci :
var foo = a + ( b * c ) ;Cependant, Prettier supprime de nombreuses parenthèses « inutiles » et revient à :
var foo = a + b * c ;Si vous souhaitez utiliser cette règle avec Prettier, vous devez diviser l'expression en une autre variable :
var bar = b * c ;
var foo = a + bar ;Gardez cependant à l’esprit que Prettier imprime quelques parenthèses « inutiles » :
var foo = ( a && b ) || c ;Exemple de configuration ESLint :
{
"rules" : {
"no-mixed-operators" : " error "
}
}Cette règle nécessite certaines options.
Cette règle interdit l'utilisation de caractères de tabulation. Par défaut, la règle interdit tous les caractères de tabulation. Cela peut être très bien utilisé avec Prettier tant que vous ne configurez pas Prettier pour qu'il indente à l'aide de tabulations.
Heureusement, il est possible de configurer la règle pour qu'elle fonctionne indépendamment du fait que Prettier utilise des espaces ou des tabulations : définissez allowIndentationTabs sur true . De cette façon, Prettier s'occupe de votre indentation, tandis que no-tabs s'occupe des caractères de tabulation potentiels ailleurs dans votre code.
Exemple de configuration ESLint :
{
"rules" : {
"no-tabs" : [ " error " , { "allowIndentationTabs" : true }]
}
}Cette règle nécessite une attention particulière lors de l’écriture du code.
Cette règle interdit les expressions multilignes confuses dans lesquelles une nouvelle ligne semble terminer une instruction, mais ce n'est pas le cas.
Par exemple, la règle pourrait avertir de ceci :
var hello = "world"
[ 1 , 2 , 3 ] . forEach ( addNumber )Prettier formate généralement ceci d'une manière qui montre clairement qu'il manque un point-virgule :
var hello = "world" [ ( 1 , 2 , 3 ) ] . forEach ( addNumber ) ; Cependant, il existe des cas où Prettier divise les choses en plusieurs lignes, de sorte qu'il no-unexpected-multiline .
const value = text . trim ( ) . split ( "n" ) [ position ] . toLowerCase ( ) ;Prettier le divise cependant en plusieurs lignes, provoquant un conflit :
const value = text
. trim ( )
. split ( "n" )
[ position ] . toLowerCase ( ) ;Si vous aimez cette règle, elle peut généralement être utilisée avec Prettier sans problème, mais vous devrez parfois désactiver temporairement la règle ou refactoriser votre code.
const value = text
. trim ( )
. split ( "n" )
// eslint-disable-next-line no-unexpected-multiline
[ position ] . toLowerCase ( ) ;
// Or:
const lines = text . trim ( ) . split ( "n" ) ;
const value = lines [ position ] . toLowerCase ( ) ;Remarque : Si vous activez cette règle, vous devez exécuter ESLint et Prettier en deux étapes distinctes (et ESLint en premier) afin d'en tirer une valeur. Sinon, Prettier pourrait reformater votre code de telle manière qu'ESLint n'ait jamais la possibilité de signaler quoi que ce soit (comme le montre le premier exemple).
Exemple de configuration :
{
"rules" : {
"no-unexpected-multiline" : " error "
}
}(Ce qui suit s'applique également à babel/quotes et @typescript-eslint/quotes.)
Cette règle nécessite certaines options et certaines options plus jolies.
Habituellement, vous n’avez pas du tout besoin de cette règle. Mais il y a deux cas où cela pourrait être utile :
Si vous souhaitez que toutes les chaînes utilisent des guillemets (jamais des guillemets), activez l'option "backtick" .
Exemple de configuration ESLint :
{
"rules" : {
"quotes" : [ " error " , " backtick " ]
}
}Dans l'exemple suivant, le premier élément du tableau aurait pu être écrit avec des guillemets au lieu de guillemets.
const strings = [
`could have been a regular string` ,
`
multiple
lines
` ,
`uses ${ interpolation } ` ,
String . raw `tagged/` ,
] ; Si vous souhaitez qu'ESLint impose que `could have been a regular string` soit écrit comme "could have been a regular string" ou 'could have been a regular string' , vous devez utiliser une configuration spécifique. La règle quotes a deux options, une option de chaîne et une option d'objet.
"single" ou "double" et être synchronisée avec l'option singleQuote de Prettier."avoidEscape": true pour suivre les règles de formatage de chaîne de Prettier."allowTemplateLiterals": false pour interdire les backticks inutiles. ESLint :
{
"rules" : {
"quotes" : [
" error " ,
" double " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}Plus joli (c'est la valeur par défaut, il n'est donc pas nécessaire de l'ajouter) :
{
"singleQuote" : false
}ESLint :
{
"rules" : {
"quotes" : [
" error " ,
" single " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}Plus joli :
{
"singleQuote" : true
}Cette règle peut être utilisée avec certaines options.
Cette règle corrigera automatiquement l'indentation des modèles de chaînes multilignes, afin de les maintenir alignés avec le code dans lequel ils se trouvent. Une liste blanche configurable est utilisée pour garantir qu'aucune chaîne sensible aux espaces n'est modifiée.
Des offres plus jolies avec :
Utilisation de diverses balises, fonctions et commentaires.
unicorn/template-indent formate par défaut certains des mêmes modèles balisés, ce qui peut provoquer des conflits. Par exemple, la règle et Prettier ne sont pas d'accord sur l'indentation dans les ternaires :
condition
? null
: html `
< p >
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam in dui
mauris.
</ p >
` ;Si vous aimez cette règle, elle peut très bien être utilisée avec Prettier tant que vous configurez la règle pour ne pas traiter les mêmes modèles que Prettier.
Exemple de configuration ESLint :
{
"rules" : {
"unicorn/template-indent" : [
" error " ,
{
"tags" : [
" outdent " ,
" dedent " ,
" sql " ,
" styled "
],
"functions" : [
" dedent " ,
" stripIndent "
],
"selectors" : [],
"comments" : [
" indent "
]
}
]
}
} Remarque : Si vous utilisez "selectors" , l'outil d'assistance CLI ne peut pas détecter si vos sélecteurs peuvent provoquer des conflits.
Cette règle nécessite certaines options.
Cette règle détermine si les éléments doivent se fermer automatiquement ou non.
Prettier préserve généralement la façon dont vous avez écrit vos éléments :
< div />
< div ></ div >
< MyComponent />
< MyComponent ></ MyComponent >
< svg >< path d = " " /></ svg >
< svg >< path d = " " ></ path ></ svg > Mais pour les éléments HTML vides connus, Prettier utilise toujours le style à fermeture automatique. Par exemple, <img> est transformé en <img /> .
Si vous aimez cette règle, elle peut être utilisée très bien avec Prettier tant que vous définissez html.void sur "any" .
Exemple de configuration ESLint :
{
"rules" : {
"vue/html-self-closing" : [
" error " ,
{
"html" : {
"void" : " any "
}
}
]
}
}Ces règles ne sont pas en conflit avec Prettier, mais présentent quelques pièges lorsqu'elles sont utilisées avec Prettier.
Cette règle interdit d'utiliser l'opérateur virgule déroutant de JavaScript (expressions de séquence). Ce morceau de code ne fait pas ce à quoi il ressemble :
matrix [ 4 , 7 ] ;Prettier ajoute des parenthèses à ce qui précède pour indiquer clairement qu'une expression de séquence est utilisée :
matrix [ ( 4 , 7 ) ] ; Cependant, la règle no-sequences autorise les opérateurs virgules si la séquence d'expression est explicitement entourée de parenthèses. Étant donné que Prettier les met automatiquement entre parenthèses, vous ne verrez peut-être jamais d'avertissements d'ESLint concernant les opérateurs virgules.
Se retrouver avec une expression de séquence accidentelle peut facilement se produire lors de la refactorisation. Si vous souhaitez qu'ESLint détecte de telles erreurs, il est recommandé d'interdire entièrement les expressions de séquence utilisant une syntaxe sans restriction (comme mentionné dans la documentation no-sequences ) :
{
"rules" : {
"no-restricted-syntax" : [ " error " , " SequenceExpression " ]
}
} Si vous devez toujours utiliser l'opérateur virgule pour certains cas extrêmes, vous pouvez placer un commentaire // eslint-disable-next-line no-restricted-syntax sur la ligne au-dessus de l'expression. no-sequences peuvent être désactivées en toute sécurité si vous utilisez l'approche no-restricted-syntax .
Vous pouvez également fournir un message personnalisé si vous le souhaitez :
{
"rules" : {
"no-restricted-syntax" : [
" error " ,
{
"selector" : " SequenceExpression " ,
"message" : " The comma operator is confusing and a common mistake. Don’t use it! "
}
]
}
}Voir package.json pour les versions exactes des plugins ESLint, Prettier et ESLint avec lesquels eslint-config-prettier a été testé.
De nouvelles règles ont-elles été ajoutées depuis ces versions ? Avons-nous oublié des règles ? Y a-t-il un plugin pour lequel vous aimeriez voir des exclusions ? Ouvrez un ticket ou une pull request !
Si vous souhaitez ajouter la prise en charge d'eslint-plugin-foobar, voici comment procéder :
Tout d’abord, ajoutez des règles à index.js :
"foobar/some-rule" : "off" Ensuite, créez test-lint/foobar.js :
/* eslint-disable quotes */
"use strict" ;
// Prettier does not want spaces before the parentheses, but
// `plugin:foobar/recommended` wants one.
console . log ( ) ; test-lint/foobar.js doit échouer lorsqu'il est utilisé avec eslint-plugin-foobar et eslint-plugin-prettier en même temps – jusqu'à ce qu'eslint-config-prettier soit ajouté à la configuration ESLint. Le fichier doit être formaté selon Prettier, et ce formatage doit être en désaccord avec le plugin.
Enfin, vous devez mentionner le plugin à plusieurs endroits :
package.json ..eslintrc.base.js et eslint.base.config.js .README.md . Lorsque vous avez terminé, exécutez npm test pour vérifier que tout va bien. Il exécute plusieurs autres scripts npm :
"test:prettier" vérifie que Prettier a été exécuté sur tous les fichiers."test:eslint" s'assure que les fichiers dans test-lint/ passent ESLint lorsque les exclusions de eslint-config-prettier sont utilisées. Il lint également le code d'eslint-config-prettier lui-même."test:lint-verify-fail" est exécuté par un test dans test/lint-verify-fail.test.js ."test:lint-rules" est exécuté par un test dans test/rules.test.js ."test:jest" exécute des tests unitaires qui vérifient un certain nombre de choses :"test:cli-sanity" et "test:cli-sanity-warning" sont des contrôles d'intégrité pour la CLI. MIT.
