Tslint: no-unused-variable TypeError: Eigenschaft '1' von null kann nicht gelesen werden

Guter Fund @hotforfeature. Ich habe angefangen, dies in https://github.com/palantir/tslint/pull/3919 zu behandeln, da es sich auf einige Änderungen in TS 2.9 bezog, die dieses Problem nur noch verschlimmern.

Mein PR verhindert, dass eine Ausnahme ausgelöst wird, ignoriert jedoch einfach ignorePattern in den von Ihnen erwähnten Fällen, was nicht großartig ist. Ich glaube, wir müssen etwas komplexen Code hinzufügen, wie wir es gerade für den Import von Autofixes tun :/

Ich frage mich, ob wir darüber nachdenken sollten, diese Regel abzulehnen. tsc bietet jetzt eine Möglichkeit, seine Warnungen zu ignorieren, und bietet Unterstützung für automatische Korrekturen seiner Warnungen durch eine IDE.

Soweit ich sehen kann, ist der Hauptvorteil dieser Regel ignore-pattern , aber es ist schwierig, dies richtig zu implementieren, so wie die Regel jetzt geschrieben wird, um von der tsc-Diagnose abzuhängen. TSLint ist auch etwas flexibler als tsc in Bezug auf das Deaktivieren von Regeln in bestimmten Dateien. @suchanlee irgendwelche Gedanken zu all dem? Ich weiß, dass du diese Regel vor kurzem korrigiert hast

Mein Hauptanwendungsfall für diese Regel besteht darin, Probleme beim Commit in einem Git-Hook beim Linting automatisch zu beheben. Ich denke also immer noch, dass es hier einen großen Wert gibt, auch wenn tsc etwas über IDE-Integrationen anbietet.

@JKillian Ich denke, dass die Unterstützung der Regel mit der Unterstützung von TSLint für mehrere Versionen von Typescript und den fortlaufenden Änderungen des Typescript-Verhaltens immer teurer wird. Und da Typescript die Funktion unterstützt, sollten wir dazu tendieren. Aber da frühere Versionen von TS es nicht unterstützen, denke ich nicht, dass wir es löschen sollten. Ich denke jedoch, dass wir darüber nachdenken sollten, die Regel abzuschaffen und mit den TS-Leuten zusammenzuarbeiten, um die aktuellen TSLint-Workflows mit TS besser zu unterstützen.

Ich würde den Vorschlag von @suchanlee unterstützen. Diese Regel kommt anscheinend oft in Fragen vor. Zu viele, wenn man bedenkt, dass neuere TS-Versionen angemessen vor dem Problem warnen. Lassen Sie es uns auslaufen!

@hotforfeature - Bestätigen Sie Ihren Anwendungsfall und finden Sie ihn vernünftig. Aufgrund der Komplexität der Regel denke ich jedoch, dass wir sie ablehnen werden (siehe Nr. 3919).

Wie immer ist jedoch jeder willkommen, den Quellcode der Regel zu kopieren und in ein externes Paket zu verschieben und auf diese Weise weiter zu verwenden/zu verbessern!

Für was es wert ist:

{
  "compilerOptions":  {
    "noUnusedLocals": true,
    "noUnusedParameters": true,
  }
}

Wenn Sie das obige in tsconfig kann die lint-Regel no-unused-variable deaktiviert werden.

no-unused-variable ist jetzt veraltet und das obige compilerOptions ist jetzt die offizielle Lösung.

Die Definition von noUnusedLocals und noUnusedParameters in compilerOptions ist nicht ganz dasselbe wie no-unused-variable tslint. Ab sofort stürzen ungenutzte Vars entweder den Build ab oder bleiben unbemerkt und es gibt keinen Warnmodus mehr 😞

@giladgray , @killtheliterate schrieb:

Wenn Sie das Obige in tsconfig verwenden, kann die No-Unused-Variable-lint-Regel deaktiviert werden.

Ich möchte diese Regel nicht deaktivieren, denn wie @kachkaev schrieb

noUnusedLocals und noUnusedParameters in compilerOptions ist nicht ganz dasselbe wie no-unused-variable tslint

Mein Anwendungsfall ist generierter Code. Ich möchte, dass mein manuell geschriebener Code dieser Regel folgt, aber um den Code-Generator nicht zu komplex zu machen, möchte ich diese Regel im generierten Code (oder zumindest in einigen Abschnitten des generierten Codes) deaktivieren - das ist etw, das kann' nicht mit TypeScript-Compiler-Optionen

Zumindest sollte diese Einstellung auf voll und ganz zu, dass diese

Diese Abwertung ist lächerlich. Die Compiler-Flags sind ein SCHRECKLICHER Ersatz. Sie brechen den Build und reparieren sich nicht selbst. Wie ist das eine vernünftige Lösung, um die Leute darauf hinzuweisen? Wenn die Option ignore-pattern jetzt zu schwer ist, um sie zum Laufen zu bringen, verwerfen Sie sie stattdessen.

👋 Leute - verlinke dies einfach mit https://github.com/palantir/tslint/issues/4232. Es ist allgemein bekannt und vereinbart, dass die eingebauten Compiler-Optionen _kein_ ausreichender Ersatz für no-unused-variable . Die ursprüngliche Implementierung der Regel funktionierte nicht gut mit anderen TS-Tools und musste deaktiviert werden. #4232 verfolgt einen Weg, es wieder zu aktivieren.

In der Zwischenzeit könnten Sie etwas wie tsc --noEmit --noUnusedLocals --noUnusedParameters als separates Tool verwenden, um die integrierten Prüfungen zu verwenden. Ja, das ist nicht so gut wie ein konfigurierbares no-unused-variables .

Fortsetzung der Diskussion in #4100 & #4232