Html5-boilerplate: RFC: Migration zu ESLint

Jemand? Ich bin zufrieden, den Status Quo zu verlassen. ESLint ist großartig, aber ich muss überzeugt sein, um die Änderung vorzunehmen (und dann müsste jemand die Änderung in einer PR vornehmen). Ich werde dies für eine weitere Woche offen lassen und wenn es keine Aktion gibt, werde ich schließen.

Ich kann PR dafür. ESLint ist wohl eines der am häufigsten verwendeten Tools im Javascript-Ökosystem.

http://www.npmtrends.com/eslint-vs-jshint

@roblarsen Ich bin total an @amilajacks Seite,
Ich habe einen kurzen Vergleich zwischen den beiden mit einigen Daten gemacht, die ich aus dem Internet gesammelt habe, wenn Sie einen Blick darauf werfen möchten.

Danke Leute. Das ist tolles Zeug. Möchte noch jemand mitmachen?

@amilajack danke für das Angebot an PR. Es wird wirklich geschätzt.

@roblarsen Gern geschehen !
@amilajack Fühlen Sie sich frei, mir eine Nachricht zu

@amilajack Arbeitest du noch daran?

@ryzokuken Es gibt eine offene PR, die ich mir ansehen und zusammenführen muss. # 1930

Ich würde empfehlen, sich Standard anzuschauen, der zusätzlich zu ESLint verfügbar ist und sehr beliebt ist. Um ehrlich zu sein, ist es eine Erleichterung, die Wartung von ESLint-Konfigurationen endgültig einzustellen ...

@ArmorDarks Obwohl ich den Standardstil mag, finde ich es nicht gut, andere dazu zu

So sehr ich die Flexibilität der Programmiersprache mag, hat ein solcher Vorteil seinen Preis, und die Frage ist, ob wir bereit sind, diesen Preis zu zahlen. Strengere Regeln machen den Code fast immer verständlicher und damit zuverlässiger, selbst wenn das Projekt wächst.

Darüber hinaus gewinnen Semikolons durch Beliebtheit, wobei der JavaScript-Styleguide von Airbnb als Beispiel dient: eines der am häufigsten markierten Repositories auf GitHub und höhere Download-Nummern auf NPM. [1] [2] [3] [4]

Außerdem müssten wir alle JavaScript-Dateien aktualisieren, da alle bereits Semikolons verwenden. [5] [6]

Daher glaube ich nicht, dass dieses Thema das Bikeshedding wert

Verweise:

[1] https://github.com/airbnb/javascript
[2] https://www.npmjs.com/package/eslint-config-airbnb-base
[3] https://www.npmjs.com/package/eslint-config-airbnb
[4] https://www.npmjs.com/package/eslint-config-standard
[5] https://github.com/h5bp/html5-boilerplate/blob/master/gulpfile.babel.js
[6] https://github.com/h5bp/html5-boilerplate/blob/master/src/js/plugins.js

Das alles wird sowieso auf Codestyle-Streitigkeiten hinauslaufen. Ich schlage nur eine kampferprobte Alternative vor.

Übrigens sollte ich hervorheben, dass unabhängig davon, mit welcher Option das Boilerplate verwendet wird (sei es ESLint mit projektspezifischen Regeln, sei es die beliebte ESLint-Konfiguration wie Airbnb oder Standard), es den Benutzern ohnehin etwas aufzwingen wird, dem sie folgen müssen. Es geht also nur darum, was genau durchgesetzt wird.

An dieser Stelle möchte ich mit möglichst geringer Unterbrechung auf eslint umsteigen. Dazu gehört, dass wir die bestehenden Regeln, die wir im Großhandel eingeführt haben, wegblasen, ohne zumindest darüber zu diskutieren, wie neue Regeln aussehen sollten (weshalb die bestehende PR für eslint DOA ist).

Ich werde zum Beispiel auf dem Hügel der Semikolons sterben.

Als Hinweis: Die tatsächlichen Konsumenten des Regelsatzes sind auf die Betreuer und alle beschränkt, die gewissenhaft PRs erstellen und ihren Code tatsächlich testen. Wir werden keine eslintrc in der Ferne versenden. Der eigentliche Vorteil in Bezug auf das Projekt ist, dass wir es tun und als Beispiel dafür dienen können, wie ein guter Webentwickler aussehen sollte.

Ich werde zum Beispiel auf dem Hügel der Semikolons sterben.

Das sind nur ein paar Striche mit Regex, wissen Sie. Aber ob man sie für manche Leute benutzt oder nicht, scheint tatsächlich ein schmerzhaftes Thema zu sein ...

Wir werden keine Eslintrc in der Ferne versenden. Der eigentliche Vorteil des Projekts besteht darin, dass wir es tun und als Beispiel dafür dienen können, wie ein guter Webentwickler aussehen sollte.

Sie versenden jedoch den JS-Code, der in anderen Projekten enthalten sein wird, die später fusselig werden, und die Benutzer werden gezwungen, ihn entsprechend ihren Regeln zu bearbeiten oder HTML5Boilerplate-Regeln zu verwenden. Aus diesem Grund sollte JS so nah wie möglich an den Standards der JS-Community sein, und ich denke, dass es unvermeidlich ist, einige notwendige Änderungen an Regeln und Codestyle vorzunehmen. Und eigentlich nicht so problematisch - Standard und ESLint mit --fix beheben automatisch den größten Teil des eingeführten Regelfehlers.

Das eigentliche Problem ist, was als Community-Standard in der JS-Welt zu beachten ist.

Gute Argumente. Es ist gut, an die Downstream-Effekte selbst der geringen Menge an JS erinnert zu werden, die wir versenden.

Und um zu verdeutlichen, bin ich nicht gegen Änderungen. Was ich nicht tun möchte, ist, umfassende Änderungen ohne Diskussion vorzunehmen (also danke, dass Sie Teil der Diskussion sind 👍). Obwohl ich ziemlich verzweifelt bin, 6.0 jetzt aus der Tür zu bekommen, bin ich im Allgemeinen nicht in der Eile, Änderungen vorzunehmen hier, es sei denn, sie sind die richtigen Änderungen.

Eine Möglichkeit besteht darin, die Konfiguration eslint:recommended anzuwenden, die häufig auftretende Probleme meldet, aber keine stilistischen Präferenzen auferlegt. In diesem Fall würde ESLint nur dazu dienen, Fehler und Bugs zu vermeiden. Es ist wirklich eine Art minimale Konfiguration mit gesundem Menschenverstand.

Die einzigen stilbezogenen Regeln, die ich in diesem Fall hinzufügen möchte, sind die in Ihrem .editorconfig : keine nachgestellten Leerzeichen, 4 Leerzeicheneinrückungen und endgültigen Zeilenumbrüche.

4 Leerzeichen

Nur zur Information, keiner der gängigen Codestile mit 4 Leerzeichen wird mehr eingerückt.

https://github.com/h5bp/html5-boilerplate/issues/1913#issuecomment -377298563 (eslint: empfehlen) klingt gut, obwohl ich https://github.com/h5bp/html5-boilerplate/ persönlich bevorzuge

Scherzhaft: https://github.com/christophwitzko/semicolon-indent#semicolon -indent

Ich bin auch bei Standard, weil sie nicht nur eine gute Konfiguration mit Validierung durch die Community beibehalten, sondern auch exzellente getestete Ergänzungen zusätzlich zu ESLint liefern.

Aber nur um fair zu sein, sollte ich auch Prettier erwähnen. Meine Stimme steht jedoch immer noch für Standard.

Erinnerung von früher in der Diskussion

Ich werde zum Beispiel auf dem Hügel der Semikolons sterben.

Stellen Sie sich vor, es ist ein überlebendes Spiel und wir entscheiden uns wie im Jahr 2005 für Tabs gegen Leerzeichen.

Übrigens, erwähnenswert ist die Sache mit Prettier - es sollte mit einer guten ESLint-Konfiguration kombiniert werden, da Prettier hauptsächlich Code-Stil beibehält, während ESLint-Konfigurationen (und insbesondere die von Standard) auch viele nicht-stilistische gute oder schlechte Praktiken abdecken.