eslint config prettier
1.0.0
Schaltet alle Regeln aus, die unnötig sind oder mit Prettier in Konflikt geraten könnten.
Auf diese Weise können Sie Ihre bevorzugte gemeinsam nutzbare Konfiguration verwenden, ohne dass deren stilistische Auswahl bei der Verwendung von Prettier im Weg steht.
Beachten Sie, dass diese Konfiguration nur Regeln deaktiviert, sodass es nur sinnvoll ist, sie zusammen mit einer anderen Konfiguration zu verwenden.
Installieren Sie eslint-config-prettier:
npm install --save-dev eslint-config-prettier
Fügen Sie eslint-config-prettier zu Ihrer ESLint-Konfiguration hinzu – entweder zu eslintrc oder zu eslint.config.js (flache Konfiguration).
eslintrc: Fügen Sie "prettier" zum „extends“-Array in Ihrer .eslintrc.* -Datei hinzu. Stellen Sie sicher, dass es an letzter Stelle steht, damit andere Konfigurationen überschrieben werden können.
{
"extends" : [
" some-other-config-you-use " ,
" prettier "
]
}eslint.config.js (flache Konfiguration): Importieren Sie eslint-config-prettier und fügen Sie es in das Konfigurationsarray ein – nach anderen Konfigurationen, die Sie überschreiben möchten.
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
eslintConfigPrettier ,
] ; Führen Sie abschließend das CLI-Hilfstool aus, um Probleme in den "rules" -Abschnitten Ihrer Konfiguration zu finden.
Verwenden Sie eslint-plugin-prettier? Schauen Sie sich die empfohlene Konfiguration von eslint-plugin-prettier an.
eslint-config-prettier deaktiviert nicht nur die Kernregeln , sondern auch einige dieser Plugins automatisch:
Hinweis: Möglicherweise finden Sie im Internet Anleitungen, die besagen, dass Sie auch Dinge wie
"prettier/react"erweitern sollten. Seit Version 8.0.0 von eslint-config-prettier müssen Sie nur noch"prettier"erweitern! Das beinhaltet alle Plugins.
Bei der flachen Konfiguration können Sie den Namen des Plugins selbst bestimmen! Zum Beispiel:
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 ,
] ; Man könnte erwarten, dass eslint-config-prettier ts/indent deaktiviert, aber das wird nicht der Fall sein! Weil eslint-config-prettier nur @typescript-eslint/indent deaktiviert. Es kann nicht wissen, wie Sie das Plugin aufgerufen haben. Das Gleiche gilt für das CLI-Hilfstool.
Halten Sie sich einfach an die offiziellen Plugin-Namen und schon ist alles gut.
Wenn Sie auf eine freigegebene Konfiguration stoßen, die einen nicht standardmäßigen Plugin-Namen verwendet, bitten Sie sie, stattdessen den Standardnamen zu verwenden.
Einige der Regeln, die eslint-config-prettier deaktiviert, sind möglicherweise veraltet oder werden sogar aus ESLint entfernt. Das ist völlig in Ordnung, aber wenn Sie die veralteten und entfernten Regeln wirklich weglassen müssen, können Sie dies tun, indem Sie die Umgebungsvariable ESLINT_CONFIG_PRETTIER_NO_DEPRECATED auf einen nicht leeren Wert setzen. Zum Beispiel:
env ESLINT_CONFIG_PRETTIER_NO_DEPRECATED=true npx eslint-find-rules --deprecated index.js
eslint-config-prettier wird außerdem mit einem kleinen CLI-Tool geliefert, mit dem Sie überprüfen können, ob Ihre Konfiguration Regeln enthält, die unnötig sind oder mit Prettier in Konflikt stehen. So führen Sie es aus:
npx eslint-config-prettier path/to/main.js
(Ändern Sie path/to/main.js in eine Datei, die in Ihrem Projekt vorhanden ist.)
Schauen wir uns nun an, was es tut und warum Sie es verwenden möchten.
In diesem eslintrc-Beispiel ist eine widersprüchliche Regel "indent" aktiviert:
{
"extends" : [
" some-other-config-you-use " ,
" prettier "
],
"rules" : {
"indent" : " error "
}
} Für eslintrc gilt: Während die "prettier" -Konfiguration problematische Regeln in "some-other-config-you-use" deaktivieren kann, kann sie "rules" nicht berühren! (So funktioniert ESLint – Sie können damit von Ihnen erweiterte Konfigurationen überschreiben.) Das CLI-Hilfstool meldet, dass "indent" mit Prettier in Konflikt steht, sodass Sie es entfernen können. (Was schön ist – Vereinfachung Ihrer Konfiguration!)
In diesem eslint.config.js-Beispiel (flache Konfiguration) ist auch eine widersprüchliche Regel "indent" aktiviert:
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
eslintConfigPrettier ,
{
rules : {
indent : "error" ,
} ,
} ,
] ;Mit dem neuen „Flat Config“-Format von ESLint können Sie selbst steuern, welche Dinge was überschreiben. Eine Möglichkeit, den oben genannten Konflikt zu lösen, besteht darin, die Konfigurationsobjekte neu anzuordnen, sodass eslint-config-prettier an letzter Stelle steht:
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
] ; Ein Blick auf die obige Konfiguration könnte jedoch verwirrend wirken. Es sieht so aus, als ob wir die indent aktivieren, aber in Wirklichkeit ist sie dank der Zeile eslintConfigPrettier darunter deaktiviert. Stattdessen möchten Sie möglicherweise tatsächlich Ihre eigenen Regeln nach „eslint-config-prettier“ haben und das CLI-Hilfstool ausführen, um Probleme herauszufinden, damit Sie widersprüchliche Regeln vollständig aus der Konfigurationsdatei entfernen können (was Ihre Konfiguration vereinfacht).
Theoretisch müssen Sie das Tool für jede einzelne Datei in Ihrem Projekt ausführen, um 100 % sicher zu sein, dass es keine widersprüchlichen Regeln gibt, da ESLint unterschiedliche Regeln für verschiedene Dateien unterstützt. Normalerweise gelten für alle Dateien ungefähr die gleichen Regeln, daher reicht es aus, den Befehl für eine Datei auszuführen. Wenn Sie jedoch mehrere Konfigurationsdateien oder Überschreibungen verwenden, können Sie mehrere Dateien zur Überprüfung bereitstellen:
npx eslint-config-prettier index.js test/index.js legacy/main.js
Genau wie ESLint selbst können Sie das CLI-Hilfstool eslint-config-prettier mithilfe der Umgebungsvariablen ESLINT_USE_FLAT_CONFIG steuern:
ESLINT_USE_FLAT_CONFIG=true : Nur eslint.config.js verwenden (flache Konfiguration).ESLINT_USE_FLAT_CONFIG=false : Nur eslintrc-Dateien verwenden.Warnung
Für eslint.config.js (flache Konfiguration) importiert das CLI-Hilfstooleslint/use-at-your-own-risk, was jederzeit abbrechen kann.
Eslint-config-prettier-Versionen vor 7.0.0 hatten ein etwas anderes CLI-Tool, das auf andere Weise ausgeführt wurde. Zum Beispiel:
npx eslint --print-config index.js | npx eslint-config-prettier-check
Wenn Sie so etwas in einem Tutorial finden, sieht der Befehl in 7.0.0 oder höher so aus:
npx eslint-config-prettier index.js
Es gibt einige Regeln, die eslint-config-prettier deaktiviert, die in einigen Fällen tatsächlich aktiviert werden können.
--fix verwendet werden. Für maximale Benutzerfreundlichkeit sind die Sonderregeln standardmäßig deaktiviert (vorausgesetzt, Sie schließen alle benötigten Dinge in "extends" ein). Wenn Sie sie möchten, müssen Sie sie explizit in Ihrer ESLint-Konfiguration angeben.
Diese Regeln können bei Verwendung von eslint-plugin-prettier und --fix zu Problemen führen.
Weitere Informationen finden Sie im Artikel arrow-body-style und prefer-arrow-callback .
Es gibt verschiedene Möglichkeiten, diese Regeln zu deaktivieren:
"plugin:prettier/recommended" in Ihre "extends" . Das ist die empfohlene Konfiguration von eslint- plugin -prettier."prettier/prettier" in Ihre "extends" . (Ja, es gibt sowohl eine Regel namens "prettier/prettier" als auch eine Konfiguration namens "prettier/prettier" .) Es spielt keine Rolle, welchen Ansatz Sie verwenden. "plugin:prettier/recommended" ist wahrscheinlich das einfachste.
Hinweis: Das CLI-Tool meldet diese nur dann als problematisch, wenn die Regel "prettier/prettier" für dieselbe Datei aktiviert ist.
Diese Regeln können sicher angewendet werden, wenn Sie eslint-plugin-prettier nicht verwenden. Mit anderen Worten: Wenn Sie eslint --fix und prettier --write als separate Schritte ausführen.
Diese Regel erfordert bestimmte Optionen.
Wenn ein Block (zum Beispiel nach if , else , for oder while ) nur eine Anweisung enthält, erlaubt JavaScript das Weglassen der geschweiften Klammern um diese Anweisung. Diese Regel erzwingt, ob und wann diese optionalen geschweiften Klammern weggelassen werden sollen.
Wenn Sie die Option "multi-line" oder "multi-or-nest" verwenden, kann es zu Konflikten zwischen der Regel und Prettier kommen.
Die Option "multi-line" ermöglicht beispielsweise diese Zeile:
if ( cart . items && cart . items [ 0 ] && cart . items [ 0 ] . quantity === 0 ) updateCart ( cart ) ; Prettier hält die Zeile jedoch möglicherweise für zu lang und wandelt sie in Folgendes um, was die Option "multi-line" nicht zulässt:
if ( cart . items && cart . items [ 0 ] && cart . items [ 0 ] . quantity === 0 )
updateCart ( cart ) ; Wenn Ihnen diese Regel gefällt, kann sie problemlos mit Prettier verwendet werden, solange Sie nicht die Option "multi-line" oder "multi-or-nest" verwenden.
Beispiel einer ESLint-Konfiguration:
{
"rules" : {
"curly" : [ " error " , " all " ]
}
}(Das Folgende gilt auch für @typescript-eslint/lines-around-comment.)
Diese Regel kann mit bestimmten Optionen verwendet werden.
Diese Regel erfordert Leerzeilen vor und/oder nach Kommentaren. Prettier behält Leerzeilen bei, mit zwei Ausnahmen:
Standardmäßig erfordert ESLint in diesem Fall eine Leerzeile über dem Kommentar:
if ( result ) {
/* comment */
return result ;
}Allerdings entfernt Prettier die Leerzeile:
if ( result ) {
/* comment */
return result ;
}Wenn Ihnen diese Regel gefällt, kann sie problemlos mit Prettier verwendet werden, solange Sie eine zusätzliche Konfiguration hinzufügen, um Kommentare am Anfang und Ende von Blöcken, Objekten und Arrays zuzulassen.
Beispiel einer ESLint-Konfiguration:
{
"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
}
]
}
}(Das Folgende gilt auch für vue/max-len.)
Diese Regel erfordert beim Schreiben von Code besondere Aufmerksamkeit.
Normalerweise kümmert sich Prettier automatisch um die Einhaltung einer maximalen Zeilenlänge. Es gibt jedoch Fälle, in denen Prettier nichts tun kann, beispielsweise bei langen Zeichenfolgen, regulären Ausdrücken und Kommentaren. Diese müssen von einem Menschen aufgeteilt werden.
Wenn Sie eine noch strengere Richtlinie zur maximalen Zeilenlänge durchsetzen möchten, als Prettier automatisch bereitstellen kann, können Sie diese Regel aktivieren. Denken Sie daran, die Optionen von max-len und die Option printWidth von Prettier synchron zu halten.
Bedenken Sie, dass Sie den Code möglicherweise leicht umgestalten müssen, wenn Prettier Zeilen auf eine Weise formatiert, die die max-len -Regel nicht zulässt.
Beispiel einer ESLint-Konfiguration:
{
"rules" : {
"max-len" : [ " error " , { "code" : 80 , "ignoreUrls" : true }]
}
}Diese Regel erfordert bestimmte Optionen.
Die Regel könnte beispielsweise vor dieser Zeile warnen:
var x = a => 1 ? 2 : 3 ; Mit {allowParens: true} (der Standard seit ESLint 6.0.0) wird das Hinzufügen von Klammern als gültige Möglichkeit angesehen, die Pfeilverwirrung zu vermeiden:
var x = a => ( 1 ? 2 : 3 ) ;Während Prettier diese Klammern beibehält, werden sie entfernt, wenn die Zeile lang genug ist, um einen Zeilenumbruch einzuführen:
EnterpriseCalculator . prototype . calculateImportantNumbers = inputNumber =>
1 ? 2 : 3 ; Mit {allowParens: false} schlägt ESLint stattdessen den Wechsel zu einer expliziten Rückgabe vor:
var x = a => { return 1 ? 2 : 3 ; } ;Mit Prettier bereitet das keine Probleme.
Wenn Ihnen diese Regel gefällt, kann sie problemlos mit Prettier verwendet werden, solange die Option allowParens deaktiviert ist.
Beispiel einer ESLint-Konfiguration:
{
"rules" : {
"no-confusing-arrow" : [ " error " , { "allowParens" : false }]
}
} (Hinweis: Das CLI-Hilfstool betrachtet {allowParens: true} als Standard, was seit ESLint 6.0.0 der Fall ist. Das Tool gibt eine Warnung aus, wenn Sie den Standard verwenden, auch wenn Sie eine ältere Version von ESLint verwenden. Es Es schadet nicht, {allowParens: false} explizit festzulegen, auch wenn es technisch überflüssig ist. Auf diese Weise sind Sie auf ein zukünftiges ESLint-Upgrade vorbereitet und das CLI-Tool kann einfach gehalten werden.
Diese Regel erfordert beim Schreiben von Code besondere Aufmerksamkeit.
Diese Regel verbietet das Mischen bestimmter Operatoren wie && und || .
Die Regel könnte beispielsweise vor dieser Zeile warnen:
var foo = a + b * c ;Die Regel schlägt das Hinzufügen von Klammern vor, etwa so:
var foo = a + ( b * c ) ;Prettier entfernt jedoch viele „unnötige“ Klammern und kehrt zu Folgendem zurück:
var foo = a + b * c ;Wenn Sie diese Regel mit Prettier verwenden möchten, müssen Sie den Ausdruck in eine andere Variable aufteilen:
var bar = b * c ;
var foo = a + bar ;Beachten Sie jedoch, dass Prettier einige „unnötige“ Klammern druckt:
var foo = ( a && b ) || c ;Beispiel einer ESLint-Konfiguration:
{
"rules" : {
"no-mixed-operators" : " error "
}
}Diese Regel erfordert bestimmte Optionen.
Diese Regel verbietet die Verwendung von Tabulatorzeichen. Standardmäßig verbietet die Regel alle Tabulatorzeichen. Das kann problemlos mit Prettier verwendet werden, solange Sie Prettier nicht so konfigurieren, dass es mithilfe von Tabulatoren einrückt.
Glücklicherweise ist es möglich, die Regel so zu konfigurieren, dass sie unabhängig davon funktioniert, ob Prettier Leerzeichen oder Tabulatoren verwendet: Setzen Sie allowIndentationTabs auf true . Auf diese Weise kümmert sich Prettier um Ihre Einrückung, während no-tabs sich um potenzielle Tabulatorzeichen an anderer Stelle in Ihrem Code kümmert.
Beispiel einer ESLint-Konfiguration:
{
"rules" : {
"no-tabs" : [ " error " , { "allowIndentationTabs" : true }]
}
}Diese Regel erfordert beim Schreiben von Code besondere Aufmerksamkeit.
Diese Regel verbietet verwirrende mehrzeilige Ausdrücke, bei denen eine neue Zeile so aussieht, als würde sie eine Anweisung beenden, dies aber nicht ist.
Die Regel könnte beispielsweise davor warnen:
var hello = "world"
[ 1 , 2 , 3 ] . forEach ( addNumber )Prettier formatiert dies normalerweise so, dass deutlich wird, dass ein Semikolon fehlt:
var hello = "world" [ ( 1 , 2 , 3 ) ] . forEach ( addNumber ) ; Es gibt jedoch Fälle, in denen Prettier Dinge in mehrere Zeilen aufteilt, so dass es zu Konflikten mit der no-unexpected-multiline kommt.
const value = text . trim ( ) . split ( "n" ) [ position ] . toLowerCase ( ) ;Prettier teilt es jedoch in mehrere Zeilen auf, was zu einem Konflikt führt:
const value = text
. trim ( )
. split ( "n" )
[ position ] . toLowerCase ( ) ;Wenn Ihnen diese Regel gefällt, kann sie normalerweise problemlos mit Prettier verwendet werden. Gelegentlich müssen Sie die Regel jedoch möglicherweise vorübergehend deaktivieren oder Ihren Code umgestalten.
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 ( ) ;Hinweis: Wenn Sie diese Regel aktivieren , müssen Sie ESLint und Prettier als zwei separate Schritte ausführen (und ESLint zuerst), um einen Nutzen daraus zu ziehen. Andernfalls formatiert Prettier Ihren Code möglicherweise so neu, dass ESLint nie die Möglichkeit hat, etwas zu melden (wie im ersten Beispiel zu sehen).
Beispielkonfiguration:
{
"rules" : {
"no-unexpected-multiline" : " error "
}
}(Das Folgende gilt auch für babel/quotes und @typescript-eslint/quotes.)
Diese Regel erfordert bestimmte Optionen und bestimmte Prettier-Optionen.
Normalerweise benötigen Sie diese Regel überhaupt nicht. Aber es gibt zwei Fälle, in denen es nützlich sein könnte:
Wenn Sie möchten, dass alle Zeichenfolgen Backticks (niemals Anführungszeichen) verwenden, aktivieren Sie die Option "backtick" .
Beispiel einer ESLint-Konfiguration:
{
"rules" : {
"quotes" : [ " error " , " backtick " ]
}
}Im folgenden Beispiel hätte das erste Array-Element mit Anführungszeichen statt Backticks geschrieben werden können.
const strings = [
`could have been a regular string` ,
`
multiple
lines
` ,
`uses ${ interpolation } ` ,
String . raw `tagged/` ,
] ; Wenn Sie möchten, dass ESLint erzwingt, dass `could have been a regular string` “ entweder als "could have been a regular string" oder als 'could have been a regular string' geschrieben wird, müssen Sie eine bestimmte Konfiguration verwenden. Die quotes verfügt über zwei Optionen, eine Zeichenfolgenoption und eine Objektoption.
"single" oder "double" gesetzt und mit der singleQuote-Option von Prettier synchronisiert werden."avoidEscape": true um den String-Formatierungsregeln von Prettier zu folgen."allowTemplateLiterals": false um unnötige Backticks zu verhindern. ESLint:
{
"rules" : {
"quotes" : [
" error " ,
" double " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}Hübscher (dies ist die Standardeinstellung, daher ist das Hinzufügen nicht erforderlich):
{
"singleQuote" : false
}ESLint:
{
"rules" : {
"quotes" : [
" error " ,
" single " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}Hübscher:
{
"singleQuote" : true
}Diese Regel kann mit bestimmten Optionen verwendet werden.
Diese Regel korrigiert automatisch die Einrückung mehrzeiliger Zeichenfolgenvorlagen, um sie an den Code anzupassen, in dem sie sich befinden. Eine konfigurierbare Whitelist wird verwendet, um sicherzustellen, dass keine Leerzeichen-empfindlichen Zeichenfolgen bearbeitet werden.
Schönere Angebote mit:
Verwendung verschiedener Tags, Funktionen und Kommentare.
unicorn/template-indent formatiert standardmäßig einige der gleichen getaggten Vorlagen, was zu Konflikten führen kann. Beispielsweise sind sich die Regel und Prettier nicht einig über die Einrückung in Ternären:
condition
? null
: html `
< p >
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam in dui
mauris.
</ p >
` ;Wenn Ihnen diese Regel gefällt, kann sie problemlos mit Prettier verwendet werden, solange Sie die Regel so konfigurieren, dass sie nicht mit denselben Vorlagen wie Prettier arbeitet.
Beispiel einer ESLint-Konfiguration:
{
"rules" : {
"unicorn/template-indent" : [
" error " ,
{
"tags" : [
" outdent " ,
" dedent " ,
" sql " ,
" styled "
],
"functions" : [
" dedent " ,
" stripIndent "
],
"selectors" : [],
"comments" : [
" indent "
]
}
]
}
} Hinweis: Wenn Sie "selectors" verwenden, kann das CLI-Hilfstool nicht erkennen, ob Ihre Selektoren Konflikte verursachen könnten.
Diese Regel erfordert bestimmte Optionen.
Diese Regel legt fest, ob Elemente selbstschließend sein sollen oder nicht.
Prettier behält im Allgemeinen die Art und Weise bei, wie Sie Ihre Elemente geschrieben haben:
< div />
< div ></ div >
< MyComponent />
< MyComponent ></ MyComponent >
< svg >< path d = " " /></ svg >
< svg >< path d = " " ></ path ></ svg > Für bekanntermaßen ungültige HTML-Elemente verwendet Prettier jedoch immer den selbstschließenden Stil. Beispielsweise wird <img> in <img /> umgewandelt.
Wenn Ihnen diese Regel gefällt, kann sie problemlos mit Prettier verwendet werden, solange Sie html.void auf "any" setzen.
Beispiel einer ESLint-Konfiguration:
{
"rules" : {
"vue/html-self-closing" : [
" error " ,
{
"html" : {
"void" : " any "
}
}
]
}
}Diese Regeln stehen nicht im Widerspruch zu Prettier, weisen jedoch einige Fallstricke auf, wenn sie mit Prettier verwendet werden.
Diese Regel verbietet die Verwendung des verwirrenden Komma-Operators (Sequenzausdrücke) von JavaScript. Dieser Code macht nicht das, wonach er aussieht:
matrix [ 4 , 7 ] ;Prettier fügt oben Klammern hinzu, um deutlich zu machen, dass ein Sequenzausdruck verwendet wird:
matrix [ ( 4 , 7 ) ] ; Die no-sequences -Regel erlaubt jedoch Kommaoperatoren, wenn die Ausdruckssequenz explizit in Klammern eingeschlossen ist. Da Prettier sie automatisch in Klammern setzt, werden Sie möglicherweise nie Warnungen von ESLint zu Kommaoperatoren sehen.
Beim Refactoring kann es leicht passieren, dass ein versehentlicher Sequenzausdruck entsteht. Wenn Sie möchten, dass ESLint solche Fehler abfängt, wird empfohlen, Sequenzausdrücke mithilfe der No-Restricted-Syntax vollständig zu verbieten (wie in der no-sequences -Dokumentation erwähnt):
{
"rules" : {
"no-restricted-syntax" : [ " error " , " SequenceExpression " ]
}
} Wenn Sie für einen Randfall dennoch den Kommaoperator verwenden müssen, können Sie in der Zeile über dem Ausdruck einen // eslint-disable-next-line no-restricted-syntax Kommentar platzieren. no-sequences können sicher deaktiviert werden, wenn Sie den no-restricted-syntax Ansatz verwenden.
Sie können bei Bedarf auch eine benutzerdefinierte Nachricht angeben:
{
"rules" : {
"no-restricted-syntax" : [
" error " ,
{
"selector" : " SequenceExpression " ,
"message" : " The comma operator is confusing and a common mistake. Don’t use it! "
}
]
}
}Die genauen Versionen von ESLint, Prettier und ESLint-Plugins, mit denen eslint-config-prettier getestet wurde, finden Sie in package.json.
Wurden seit diesen Versionen neue Regeln hinzugefügt? Haben wir Regeln übersehen? Gibt es ein Plugin, für das Sie Ausschlüsse sehen möchten? Öffnen Sie ein Issue oder eine Pull-Anfrage!
Wenn Sie Unterstützung für eslint-plugin-foobar hinzufügen möchten, gehen Sie folgendermaßen vor:
Fügen Sie zunächst Regeln zu index.js hinzu:
"foobar/some-rule" : "off" Erstellen Sie dann 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 muss fehlschlagen, wenn es gleichzeitig mit eslint-plugin-foobar und eslint-plugin-prettier verwendet wird – bis eslint-config-prettier zur ESLint-Konfiguration hinzugefügt wird. Die Datei sollte gemäß Prettier formatiert sein und diese Formatierung sollte nicht mit dem Plugin übereinstimmen.
Abschließend müssen Sie das Plugin an mehreren Stellen erwähnen:
package.json hinzu..eslintrc.base.js und eslint.base.config.js verwendet wird.README.md hinzu. Wenn Sie fertig sind, führen Sie npm test aus, um zu überprüfen, ob alles in Ordnung ist. Es führt mehrere andere npm-Skripte aus:
"test:prettier" prüft, ob Prettier für alle Dateien ausgeführt wurde."test:eslint" stellt sicher, dass die Dateien in test-lint/ ESLint bestehen, wenn die Ausschlüsse von eslint-config-prettier verwendet werden. Es fusselt auch den Code von eslint-config-prettier selbst."test:lint-verify-fail" wird von einem Test in test/lint-verify-fail.test.js ausgeführt."test:lint-rules" wird von einem Test in test/rules.test.js ausgeführt."test:jest" führt Unit-Tests aus, die eine Reihe von Dingen überprüfen:"test:cli-sanity" und "test:cli-sanity-warning" sind Plausibilitätsprüfungen für die CLI. MIT.
