Tslint: Die Semikolonregel sollte unnötige Semikolons für Klassenmitgliedsfunktionen kennzeichnen

Ich bin nicht davon überzeugt, dass dies für 4.0 erforderlich ist, aber es würde auch nicht schaden, es einzubauen. Es scheint jedoch eine winzige Option zu sein, aber ich bin nicht ganz davon überzeugt, dass es die zusätzliche Komplexität wert ist

Nur als Feedback-Element (nicht sicher, ob dies der richtige Ort ist?), Wir sind gerade darüber gestolpert und waren sehr überrascht.

Ich verstehe wahrscheinlich nicht ganz die Begründung dafür, aber insbesondere, dass tslint Semikolons an dieser Position als unnötig kennzeichnet (dh nicht einfach akzeptiert, sie wegzulassen), scheint verwirrend.

Sie können das alte Verhalten mit der Option ignore-bound-class-methods wiederherstellen. Wir wollten bei der Standardkonfiguration etwas eigensinniger sein und gebundene Klassenmethoden in den meisten TS-Codes wie normale Klassenmethoden aussehen lassen.

Ja, so viel habe ich mir gedacht. Ich hätte erwartet, dass tslint dieses Semikolon standardmäßig erfordert, mehr auf der Seite der Konsistenz irrt oder das Problem ignoriert, aber das Hinzufügen dieser Option funktioniert für uns.

Ich habe versucht, dies zu erreichen, um das Werfen von Fehlern in Intellij zu stoppen

Ich habe versucht, das Semikolon hinter Klassenpfeilfunktionen zu entfernen, dann erhalte ich diese Warnung:

Ich habe versucht, die Option wie folgt zu aktivieren:

Aber ich bekomme dieses Ergebnis:

Ich habe versucht, die Option wie folgt zu aktivieren:

Aber dann hört es auf, nach Semikolons zu suchen.

tslint-Version: 4.4.2
ts-Version: 2.1.5
intellij-Version: 2016.3
Betriebssystem: Windows 10 x64

Für Leute, die zu diesem Thread kommen und nach der richtigen tslint-Konfiguration suchen (wie ich) - die richtige Syntax dafür wäre:
"Semikolon": [true, "always", "ignore-bound-class-methods"]

Siehe: https://palantir.github.io/tslint/rules/semicolon/

@popstr Ja, das verwende ich auch.

"semicolon": [true, "always", "ignore-bound-class-methods"]

Ich habe #3216 erstellt, weil das Ignorieren in Bezug auf die Konsistenz eine schlechte Idee ist und die Regel ohne die Option ignore-bound-class-methods immer noch fehlerhaft ist, wie ich herausgefunden habe.