Tslint: Warnung: Die Regel 'no-unused-variable' erfordert Typüberprüfungsnachricht...

Bitte füllen Sie die Ausgabevorlage aus. Wie sieht Ihre tslint.json aus?

Ich bin zu Hause und habe das gleiche Projekt ausprobiert und es funktioniert einwandfrei. Ich lasse das offen, bis ich am Montag wieder zur Arbeit komme, um wieder zu testen. Möglicherweise müssen nur meine Knotenmodule neu installiert werden.

Ich habe auch aktualisiert, um die Problemvorlage zu verwenden.

Irgendwann nach der Aktualisierung von tslint (vielleicht v4 -> v5) sind no-unused-variable ohne --type-check , --project Argumente nicht verfügbar.

Diese Option ist schwer zu verwenden und dauert lange, bis die Druckergebnisse nach der Aktualisierung gedruckt werden, aber eine wichtige und am häufigsten verwendete Linting-Option. Gibt es eine Möglichkeit, diese Optionen ohne obere Argumente zu verwenden?

Irgendwann nach der Aktualisierung von tslint (vielleicht v4 -> v5) sind no-unused-variable ohne --type-check, --project Argumente nicht verfügbar.

Ich übergebe --project mit tslint --type-check --project tsconfig.json src/**/*.ts

Auf meinem Heimcomputer habe ich dieses Problem nicht, aber auf meinem Arbeitscomputer schon.

@everedifice es gab Fehler bei der markiert (https://github.com/palantir/tslint/issues/1481) und letztendlich beschlossen, sie https://github.com/palantir/tslint/pull/2235.

@mastrauckas Ich kann Ihnen ohne weitere Details zu den Unterschieden zwischen Ihren beiden verschiedenen Umgebungen nicht wirklich helfen.

@adidahiya Ich habe das letzte Nacht auf einem dritten Computer bekommen, der auch ein macOS ist. Ich werde es noch einmal auf meinem Heimcomputer versuchen, um zu sehen, ob es immer noch passiert.

Im Allgemeinen:
Computer 1: Windows 10 ist auf dem neuesten Stand und im Moment bekomme ich nicht das error .
Computer 2: macOS wurde vollständig aktualisiert und ich erhalte die error .
Computer 3: Windows 7 wurde vollständig aktualisiert und ich erhalte die error .

@everedifice Ich habe gerade eine neue Version von tslint-consistent-codestyle mit einer neuen Regel no-unused die hauptsächlich wie no-unused-variable mit einigen zusätzlichen Funktionen ist, aber ohne dass --project --type-check .

Bei Interesse finden Sie die Dokumente hier: https://github.com/ajafff/tslint-consistent-codestyle/blob/master/docs/no-unused.md

Der Computer, von dem ich dachte, dass er das Problem nicht hat, scheint das Problem doch zu haben. Ist das ein Fehler?

Gibt es etwas Neues zu diesem Thema?

Ich habe das gleiche Problem.

Das gleiche Problem, aber mit beiden 'Warnung: Die 'no-unused-variable'-Regel erfordert Typinformationen.'
und 'Warnung: Die 'no-use-before-declare'-Regel erfordert Typinformationen.' (Ich kann sehen, dass der Tippfehler in 'Information' zwischen Version 5.5.0 und 5.7.0 behoben wurde, aber das ist das einzige, was sich geändert hat). Ich führe es mit Typoskriptversion 2.4.1 aus. Gibt es Neuigkeiten zu diesem Problem?

Gleiches Problem hier

Ist dieses Problem behoben oder eine vorübergehende Lösung, um die Anzeige von Warnungen zu beenden?

Ich glaube nicht, dass es behoben ist. Ich glaube nicht einmal, dass sie das als Problem akzeptiert haben.

Dauerhafte Korrektur, verwenden Sie no-unused-variable in tsconfig.json anstelle von tslint.json. Wenn der Compiler die gleiche Funktionalität bieten kann, macht es keinen Sinn, dies mit einem Linter zu tun.

@AnimaMundi Nun, es bietet die gleiche Funktionalität, aber wenn Sie tslint als Teil unseres CI-Prozesses ausführen, müssen diese während des Tests und nicht während des Builds gekennzeichnet werden. Ich bin nicht einverstanden, dass dies ignoriert / entfernt werden sollte, da der Compiler dies zur Build-Zeit tut.

@haswalt Ich sehe keinen Grund, warum es während der Linting-Phase und nicht während der Build-Phase gekennzeichnet werden muss. Egal, ob Sie mir zustimmen oder nicht, ich habe nichts mit der Entwicklung dieses Projekts zu tun. Ich habe gerade gesehen, dass jemand nach einer Lösung suchte und ihnen diese zur Verfügung stellte.

Ähnlich wie bei @AnimaMundi habe ich noUnusedLocals und noUnusedParameters in meiner tsconfig.json verwendet. Fehler werden in meinem Bereich "Probleme" angezeigt.

@AnimaMundi @haswalt @keego die Vorzüge einer Lint-Regel im Vergleich zu einer Compiler-Prüfung auf nicht verwendete Variablen wurden in anderen TSLint-Threads ausführlich diskutiert (https://github.com/palantir/tslint/issues/1481 und verlinkte Threads); dieses Thema ist nicht wirklich der richtige Ort dafür.

@adidahiya mein Kommentar sollte nur eine Lösung für dieses Problem geben, keinen Kommentar zu den Vorzügen von Linter-Regeln im Vergleich zu Compiler-Überprüfungen.

Das Zurückstellen auf den Compiler bewirkt nicht dasselbe: Der Compiler hat nur eine Option: FAIL.
Der Grund für tslint , damit umzugehen, ist, dass es oft eine Warnung sein muss (grüne Kringel vs. rote).

Tslint-Probleme können nicht nur als Warnungen angezeigt, sondern auch einmalig ignoriert werden, während Typoskript-Kompilierungsfehler nicht möglich sind

Diese Punkte wurden bereits alle herausgehasht (siehe meinen letzten Kommentar und die verlinkten Threads). Es gibt nichts, was Sie davon abhält, no-unused-variable als TSLint-Regel zu verwenden. Ich bin mir nicht sicher, was mit diesen Folgekommentaren erreicht werden soll.

@mastrauckas hast du immer noch Probleme mit dieser Regel? Das Flag --type-check ist veraltet, aber --project ist erforderlich, um auf Typprüfung basierende Regeln zu aktivieren.

Übrigens: Mit TS 2.6 können Sie mit // @ts-ignore Compilerfehler unterdrücken.

@adidahiya Ich habe lediglich auf die obigen Kommentare

aber Sie haben Recht, ich denke, das relevante Problem liegt an der vscode-Erweiterung und nicht an Tslint selbst. tbh es gab so viele Probleme zu diesem Thema, dass ich eine Weile gebraucht habe, um genau herauszufinden, warum und wo es nicht funktioniert.

schätzen den Tipp. Ich werde auf jeden Fall wieder auf die Compiler-Einstellung zurückgreifen, sobald wir zu 2.6 . wechseln

Ein weiterer Punkt für diejenigen, die behaupten, dass dies keine Flusenregel sein sollte: Flusenwarnungen können behoben werden, und dies ist ein erstklassiger Kandidat dafür.

Ich erhalte die gleiche Warnung im neuesten 1.19 VS Code The 'no-unused-variable' rule requires type information (siehe unten). Fehlt meiner Konfiguration etwas?

{
  "extends": "tslint:recommended",
  "rules": {
    "linebreak-style": [true, "LF"],
    "quotemark": [true, "single", "avoid-escape", "avoid-template"],
    "no-console": false,
    "no-unused-expression": false,
    "ordered-imports": false,
    "member-access": [true, "no-public"],
    "object-literal-sort-keys": false,
    "curly": [true, "ignore-same-line"],
    "semicolon": [true, "never"],
    "no-var-requires": false,
    "no-unused-variable": true
  }
}

Wenn Sie sich die Readme-Datei von VSCode 1.19 ansehen, gibt es eine neue Funktion, um diese und andere Regeln als Warnungen zu behandeln.
Für uns bedeutet es:

• "no-unused-variable" aus tslint.json entfernen
• füge "noUnusedLocals" zu unserem tsconfig.json

Andere Regeln bleiben dem Leser als Übungsaufgabe ;-)

Beachten Sie, dass tslint diese Erweiterung ist, während tsconfig das integrierte Verhalten von VSCode ist.

Ich habe mich dafür entschieden, no-unused-variable zu entfernen, da VS 1.19 diese anscheinend bereits meldet.

Ich verstehe nicht, was VSCode damit zu tun hat. Es reicht nicht aus, dass nur VSCode diese als Warnungen behandelt, ich muss meinen Webpack-Entwicklungsserver-Watch-Build nicht daran scheitern lassen. Gibt es einen Ersatz für no-unused-variable , der unabhängig von bestimmten Redakteuren?

• während der Entwicklung als Warnung behandelt werden
• Fail-Builds während CI

?

@pelotom , mehrere Leute wurden von der VSCode TSLint-Erweiterung hierher umgeleitet, z. B. von https://github.com/Microsoft/vscode-tslint/issues/219

Bis jetzt konnte TS einige Probleme nicht als Warnungen anzeigen (grüne Kringel), aber Fusseln (ESlint, TSLint) waren in der Lage. Wir haben uns also gefragt, warum TSlint nicht verwendete Variablen nicht als Warnungen meldet. Aber ab 1.19 kann der TS von VSCode diese Warnungen ausgeben und wir ziehen uns von diesem Problem zurück 😉

Um es klar zu sagen, ich verwende auch VSCode und würde diese Warnungen auch gerne im Editor hervorgehoben sehen, aber die Einstellungen von VSCode scheinen die falsche Ebene zu sein, um den Schweregrad von Compilerfehlern zu _konfigurieren_, da dies keinen Einfluss auf den Rest Ihrer Werkzeugkette.

Ich stimme dir Tom zu und hoffe, dass die Lösung dort gefunden wird, wo sowohl der Editor als auch unsere Build/CI-Verfahren die richtige Unterstützung haben. Bisher haben wir starke Rückschläge erlebt (scheinbar gerechtfertigt) und einige (einschließlich mir) würden heute alles nehmen, was wir können, während sie auf eine echte Lösung hoffen.

Wenn Sie sich die Readme-Datei von VSCode 1.19 ansehen, gibt es eine neue Funktion, um diese und andere Regeln als Warnungen zu behandeln.

@rnemec Ich denke, du Versionshinweise " anstelle von "Readme" schreiben. Ich war dumm genug, nach der Readme zu suchen. Und für alle, die hier ankommen, können wir genauso gut das relevante Zitat zitieren:

VS Code zeigt jetzt Probleme mit dem TypeScript-Codestil als Warnungen statt als Fehler an. Dies gilt für:

Variable ist deklariert, aber nie verwendet
Eigenschaft wird deklariert, aber ihr Wert wird nie gelesen
Nicht erreichbarer Code erkannt
Unbenutztes Etikett
Fall durch Gehäuse im Schalter
Nicht alle Befehle liefern einen Wert zurück
Diese als Warnungen zu behandeln entspricht anderen Tools wie TSLint. Diese werden weiterhin als Fehler angezeigt, wenn Sie tsc über die Befehlszeile ausführen.

Sie können dieses Verhalten deaktivieren, indem Sie Folgendes einstellen: "typescript.reportStyleChecksAsWarnings": false.

Dies ist also eine vorübergehende Lösung und würde nur bei Verwendung von VSCode funktionieren. Jedes andere Build-Tool, das tsc direkt verwendet, würde den Code nicht kompilieren, wenn die Warnungen dort belassen werden. Ich habe einige Kollegen, die Atom verwenden, daher können sie den Code nicht kompilieren, wenn ich Änderungen vornehme und eine der Warnungen ignoriere. Rechts?

Ich verstehe nicht ganz, wie das alles löst. Wie ist es sinnvoll, diese Dinge als Warnungen anzuzeigen, wenn der Compiler sie immer noch als Fehler behandelt?

Und wenn ich das richtig verstehe, wäre die langfristige Lösung, entweder ein Flag hinzuzufügen, um das gleiche Verhalten in tsc zu erzwingen (damit es mit Warnungen kompiliert wird) oder diese Compilerprüfungen vollständig zu entfernen?

--- bearbeiten ---
Ich habe nicht alle vorherigen Kommentare gelesen. @pelotom hat bereits den gleichen Punkt gemacht.

Wenn Sie möchten, dass Lint-Prüfungen im Dev-Modus und im CI-Modus einen anderen Schweregrad haben, können Sie dies mit mehreren tslint.json-Konfigurationen tun, wobei eine extends die andere ist. #2569 muss behoben werden, damit die UX hier gut ist, damit Sie den Schweregrad mit nur einer defaultSeverity Konfigurationszeile umschalten können – es ist in Bearbeitung.

@adidahiya, was diskutiert wird, ist ein angeblicher _replacement_ für die lint-Regel no-unused-variable unter Verwendung von tsc noUnusedLocals .

@pelotom richtig, das habe ich verstanden - aber ich glaube nicht, dass tsc solchen Workflow noch unterstützt. Sie könnten zwei tsconfig.json Dateien haben, von denen eine die andere erweitert und jede "nicht fatale" Compilerprüfung (in diesem Fall noUnusedLocals , noUnusedParameters ) einzeln deaktiviert, aber dies würde Lassen Sie die Überprüfungen in Ihrem Editor nicht als Warnungen anzeigen.

@adidahiya ja, deshalb ist es derzeit kein gültiger Ersatz. Und ich würde es viel lieber sehen, dass no-unused-variable in VSCode richtig funktioniert, als mehr Mühe zu investieren, damit sich noUnusedLocals eher wie eine Fusselregel verhält. IMO war es ein Fehler, dass der Compiler überhaupt versucht hat, diese Art von Prüfung zu übernehmen.

Und ich würde es viel lieber sehen, dass no-unused-variable in VSCode richtig funktioniert, als mehr Mühe zu investieren, damit sich noUnusedLocals eher wie eine Lint-Regel verhält.

Macht Sinn. Ich glaube, dieses Projekt zielt darauf ab: https://github.com/angelozerr/tslint-language-service. Sie können mit diesem Plugin Regeln verwenden, die eine Typprüfung erfordern.

Ich habe zu früh gesprochen. Wir sind auf https://github.com/palantir/tslint/issues/2649 blockiert, damit dieses Plugin nützlich ist. Verfolgen Sie dieses Problem stattdessen.

@adidahiya ja, ich verfolge es schon seit geraumer Zeit.

Gibt es darüber irgendwelche Neuigkeiten? Wird es veraltet sein oder nicht?

@philip-firstorder hat das Problem für mich behoben --project tsconfig.json

tslint -c tslint.json --project tsconfig.json src/**/*.ts

no-unused-variable ist jetzt veraltet, siehe #3918 und #3919

🤖 Beep boop! 👉 TSLint ist veraltet 👈 und Sie sollten zu typescript-eslint wechseln ! 🤖

🔒 Dieses Problem wird gesperrt, um weitere unnötige Diskussionen zu vermeiden. Dankeschön! 👋