Wie kann ich eine ESLint-Regel für “linebreak-style” schreiben, die sich je nach Windows oder Unix ändert?
Lesezeit: 6 Minuten
[*] Ravindra Thorat
Wie wir alle wissen, sind die in Windows verwendeten Zeilenumbrüche (neue Zeile) normalerweise Wagenrückläufe (CR) gefolgt von einem Zeilenvorschub (LF), dh (CRLF), während Linux und Unix einen einfachen Zeilenvorschub (LF) verwenden.
In meinem Fall unterstützt mein Build-Server jetzt das Linux- und Unix-Format, sodass die folgende Regel auf dem Build-Server perfekt funktioniert:
linebreak-style: ["error", "unix"]
Aber ich mache die Entwicklung unter Windows und muss die Regel für jeden aktualisieren Git-Pull/Git-Push wie nachstehend,
linebreak-style: ["error", "windows"]
Gibt es also eine Möglichkeit, ein Generikum zu schreiben? Zeilenumbruch-Stil Regel zur Unterstützung beider Umgebungen, Linux/Unix und Windows?
Notiz: Ich verwende ECMAScript6[js]WebStorm[ide] zur Entwicklung
Irgendwelche Lösungen/Vorschläge würden sehr geschätzt. Vielen Dank!
Warum nicht verwenden LF die ganze Zeit (für JS-Dateien)? Sowohl Browser als auch IDE unterstützen sie problemlos.
– LazyOne
24. August 2016 um 8:16 Uhr
ESLint-Tests schlagen für LF fehl, wenn die Umgebung Windows ist.
– Ravindra Thorat
24. August 2016 um 10:35 Uhr
Ich verstehe – danke für die Klarstellung (selbst keine JS-Person)
– LazyOne
24. August 2016 um 10:58 Uhr
Was passiert, wenn ich beide hinzufüge? [“error”, “unix”, “windows”]Es hilft, die Warnung in meinem Texteditor zu beheben, aber ich bin mir nicht sicher über die Build-Fähigkeit auf dem Server
– Thiện Sinh
13. April 2020 um 11:02 Uhr
Stu
Ich habe viel Zeit damit verbracht, herauszufinden, wie ich den Linkbreak-Stil abschalten kann, und habe ihn verloren, weil ich einen Teil meines Codes zurückgesetzt habe. Ich dachte, andere hätten das auch gerne.
In dem .eslintrc Datei können Sie auch festlegen linebreak-style zu 0 die abschaltet Zeilenumbruch Besonderheit:
Etwas, das Sie niemals tun sollten, besonders wenn Sie nicht der einzige Entwickler sind 😉
– Andrej Popow
20. Mai 2019 um 16:28 Uhr
Keine Lösung, nur den Schmerz verbergen.
– Benutzer959690
18. Februar 2021 um 0:03 Uhr
Ich musste den “linebreak-style” eingeben, gibt es eine Erweiterung oder etwas zur Intelligenz für alle verfügbaren Optionen?
– Sunil Garg
19. April 2021 um 8:21 Uhr
Ich könnte hier etwas vermissen, aber konvertiert Git Zeilenenden normalerweise nicht auf jeden Fall? Würde das Probleme nicht erfassen/lösen, die eslint tun würde? (Angenommen, das Team verwendet Git).
– Markieren
14. Februar um 21:16 Uhr
Vitorbal
Die eslint-Konfigurationsdatei kann sein ein Stammkunde .js Datei (dh nicht JSON, sondern vollständiges JS mit Logik), das das Konfigurationsobjekt exportiert.
Das heißt, Sie könnten die Konfiguration des ändern linebreak-style Regel abhängig von Ihrer aktuellen Umgebung (oder jeder anderen JS-Logik, die Ihnen einfällt).
Zum Beispiel, um eine andere zu verwenden linebreak-style Konfiguration, wenn Ihre Knotenumgebung „prod“ ist:
module.exports = {
"root": true,
"parserOptions": {
"sourceType": "module",
"ecmaVersion": 6
},
"rules": {
// windows linebreaks when not in production environment
"linebreak-style": ["error", process.env.NODE_ENV === 'prod' ? "unix" : "windows"]
}
};
Beispielnutzung:
$ NODE_ENV=prod node_modules/.bin/eslint src/test.js
src/test.js
1:25 error Expected linebreaks to be 'CRLF' but found 'LF' linebreak-style
2:30 error Expected linebreaks to be 'CRLF' but found 'LF' linebreak-style
3:36 error Expected linebreaks to be 'CRLF' but found 'LF' linebreak-style
4:26 error Expected linebreaks to be 'CRLF' but found 'LF' linebreak-style
5:17 error Expected linebreaks to be 'CRLF' but found 'LF' linebreak-style
6:50 error Expected linebreaks to be 'CRLF' but found 'LF' linebreak-style
7:62 error Expected linebreaks to be 'CRLF' but found 'LF' linebreak-style
8:21 error Expected linebreaks to be 'CRLF' but found 'LF' linebreak-style
✖ 8 problems (8 errors, 0 warnings)
$ NODE_ENV=dev node_modules/.bin/eslint src/test.js
$ # no errors
Aufbauend auf dieser Antwort bin ich dazu übergegangen, das normale Zeilenende für die Plattform zu erkennen, anstatt die Umgebung angeben zu müssen, also: "linebreak-style": ["error", (require("os").EOL === "\r\n" ? "windows" : "unix")]
– Brian J. Miller
18. Mai 2017 um 20:45 Uhr
Äh, Sie können die Variablen in der Entwicklungsumgebung nicht auf diese Weise festlegen, wenn die Entwicklungsumgebung Windows ist, daher ist das Beispiel für das Festlegen von NODE_ENV=dev auf diese Weise ungültig. Kannst du es korrigieren?
EditorConfig ist heutzutage eine Erweiterung für die meisten Code-Editoren ändert den Inhalt der gerade gespeicherten Datei. Diese Regel erzwingt, dass alle Zeilenenden immer sind Unix konsistent (\n) jedes Mal, wenn ein Entwickler eine Datei speichert (Hinweis: MacOs nicht mehr Verwendet \r => cr). Zur Durchsetzung Fenster Zeilenenden (\r\n) verwenden crlf.
Diese Option ist vorzuziehen, da sie verhindert, dass alle Änderungen am Zeilenende im Repository des Projekts aufgezeichnet werden (Versionskontrolle).
Wenn Sie native Zeilenenden zwischen verschiedenen Betriebssystemen verwenden möchten, ist es besser, diese Option nicht zu setzen und diese Aufgabe dem VCS zu überlassen! In der Zukunft wir könnten einen Wert wie native hinzufügen Für dieses Szenario (vgl #226).
Dies wäre ein Ersatz für die Lösung der akzeptierten Antwort:
Was immer noch besser ist, als die Regel komplett zu deaktivieren ("linebreak-style": 0): Entwickler/Mitwirkende verwenden möglicherweise ihre bevorzugten Zeilenenden in der gleichen Datei…
Das beantwortet die Frage nicht, es schaltet nur die wertvolle Funktion aus. Jetzt werden Sie mit einer Codebasis in Unordnung enden.
– Benutzer959690
18. Februar 2021 um 0:03 Uhr
Wenn Sie Vs Code unter Windows verwenden, gehen Sie zu Ihrer „.eslintrc.json“-Datei (oder „.js“, je nachdem, welche Option Sie beim Einrichten Ihres ESLint gewählt haben); diese Datei befindet sich normalerweise im Stammordner Ihres Projekts; und fügen Sie unter Regeln die Zeilenumbruchoption hinzu, um Windows CRLF wie folgt zu verwenden:
Speichern Sie die Datei und wenn Sie zu Ihrer JavaScript-Datei zurückkehren, werden all diese lästigen roten Linien verschwinden.
seanplwong
Es gibt ein paar Antworten, mit denen herumgespielt wird.eslintrc und einer schlägt sogar vor, die Regel ganz abzuschalten.
Ich ziehe es jedoch vor, die VCS-Einstellungen auf Checkout zu ändern LF Anstatt von CRLF. Angenommen, auch in Windows-Umgebungen sollte eine moderne IDE damit umgehen können LF Alles gut. Der Nachteil ist, dass einige Windows-Software wie Notepad es nicht mögen wird. Aber auf diese Weise werden Sie gewarnt, wenn Sie einen falschen Zeilenumbruchstil haben. Und es ist weniger wahrscheinlich, dass Benutzer einen falschen Zeilenumbruchstil begehen, selbst wenn ihr VCS falsch konfiguriert ist. Einfach laufen git config --global core.autocrlf false oder befolgen Sie die Anweisungen unter Wie zwinge ich Git, LF anstelle von CR+LF unter Windows zu verwenden?
Wie auch immer, es wird im Allgemeinen davon abgeraten, die Regel zu deaktivieren, da dies Auswirkungen auf andere Teammitglieder hat, es sei denn, Sie haben die Zustimmung des gesamten Teams.
Tarantino
In meinem Fall, VS-Code hatte Standardeinstellungen für den Zeilenumbruch CRLF, weil es frisch installiert wurde. Ich musste gehen, um das zu ändern, indem ich: Ctrl + Shift + P um die Befehlspalette zu öffnen und nach Folgendem zu suchen:
Änderung für Zeilenenden
Dort kannst du umschalten LF.
10364200cookie-checkWie kann ich eine ESLint-Regel für “linebreak-style” schreiben, die sich je nach Windows oder Unix ändert?yes
Warum nicht verwenden
LF
die ganze Zeit (für JS-Dateien)? Sowohl Browser als auch IDE unterstützen sie problemlos.– LazyOne
24. August 2016 um 8:16 Uhr
ESLint-Tests schlagen für LF fehl, wenn die Umgebung Windows ist.
– Ravindra Thorat
24. August 2016 um 10:35 Uhr
Ich verstehe – danke für die Klarstellung (selbst keine JS-Person)
– LazyOne
24. August 2016 um 10:58 Uhr
Was passiert, wenn ich beide hinzufüge? [“error”, “unix”, “windows”]Es hilft, die Warnung in meinem Texteditor zu beheben, aber ich bin mir nicht sicher über die Build-Fähigkeit auf dem Server
– Thiện Sinh
13. April 2020 um 11:02 Uhr