Jshint: Der Tabulatoreinzug verstößt gegen mehrere Regeln

Danke für den Bericht! Das Problem ergibt sich aus Zeile 1610 von lex.js :

this.input = this.input.replace(/\t/g, state.tab);

Dies scheint ziemlich grundlegend dafür zu sein, wie viele der stilbezogenen Linting-Regeln implementiert werden. Diese sind seit einiger Zeit veraltet, aber wir sind immer noch nicht bereit, eine neue Hauptversion zu veröffentlichen. In der Zwischenzeit müssen wir also eine Lösung entwerfen, die dieses Verhalten beibehält.

Mein erster Gedanke ist, diesen "effektiven Offset" als neue Eigenschaft des Token-Objekts mit dem Namen column zu verfolgen. Dies kann für diese stilbezogenen Warnungen verwendet werden. Dann könnte das Attribut character neu implementiert werden, um den "wahren" Zeichenversatz zu beschreiben, wobei jeder Codepunkt (Tabulator oder anderweitig) die Zählung um genau 1 erhöht. Dieser Wert würde verwendet, um Warnungen auszugeben. Reporter-Plug-ins hätten dann die Kontrolle darüber, wie sie das Tabulatorzeichen rendern, und sie könnten die gemeldete "Spalten"-Nummer entsprechend interpretieren.

Klingt das gut für dich, @Arcanemagus?

Das klingt für mich perfekt, zumindest oberflächlich ohne wirkliche Kenntnis der Interna von JSHint 😛. Idealerweise brauche ich nur eine Methode, um die wahre Spaltenanzahl zu erhalten (wobei jeder Codepunkt als eine Spalte zählt).

Dies wurde für eine Weile ausgeblendet, da diese Warnung aufgrund einer Problemumgehung für einen alten Parser-Fehler mit einem halbwegs häufigen Fehler im Wesentlichen ignoriert wurde. Als ich die Warnung für Benutzer auf eine viel nettere Weise neu implementierte, hatte ich sie versehentlich _versteckt_, und erst kürzlich wurde es behoben, wodurch dies wieder sichtbar wurde.

Anscheinend sind auch W030 , W033 und W009 betroffen. Aus Ihrer Beschreibung gehe ich davon aus, dass _alle_ Regeln betroffen sind?

Ich habe dieses Problem auch und kann sowohl Fehler als auch Warnungen replizieren. Regel/Fehlertyp scheint keine Rolle zu spielen.

Hier ist ein Beispiel für jshint, der versucht, mich zu warnen, dass mein '==' '===' sein sollte. Beachten Sie die fehlerhafte Position der orangefarbenen Unterstreichung:

Hoffentlich bestätigt dies Ihre Gedanken zu diesem Thema.

Ich habe heute etwas Zeit, um etwas zu graben, und ich glaube, dass das Setzen der Option indent auf 1 die gewünschten Ergebnisse liefern wird.

@Arcanemagus Können Sie den Wert der Option indent für Ihre Verbraucher überschreiben? Wenn dies möglich ist, würde ich das lieber tun, da ich nicht sicher bin, wie sich das Ändern des Standardwerts in JSHint selbst auf seine Verbraucher auswirken könnte.

Hmmm, derzeit verwendet dieses Projekt die CLI-Schnittstelle, wie es aussieht. Es ist möglich, es umzuschreiben, um die Node.js-API zu verwenden, was dies ermöglichen würde.

• Würde das Erzwingen des Werts indent die Ergebnisse ändern, die Verbraucher sehen? Das Ziel dieses Pakets ist es, jshint so weit wie möglich selbst auszuführen, aber die Ergebnisse in den Editor integriert zu bekommen.
• Verfügt die JSHint-API über eine versteckte Methode, um die Konfiguration für eine Datei abzurufen, oder müsste diese implementiert werden? Die aktuelle Dokumentation zeigt eine solche Funktion nicht.

Wie wäre es mit dem Hinzufügen eines Befehlszeilenarguments, mit dem Werte aus der Konfiguration überschrieben werden können?
So etwas ist in Tools wie -g in nginx, -o in ssh, -c in git und vielen mehr üblich, denke ich.

$ jshint -o "indent = 1" -o "-W034 = true" -o "globals.require = false" -o "globals.$ = null"

Weiß jemand, in welcher Version das eingeführt wurde? 2.9.5?

Zumindest könnten wir dann vorerst als Aushilfe herabstufen. Fix.

@jaredatch Zurück in https://github.com/AtomLinter/linter-jshint/pull/386 (veröffentlicht in v3.1.0 von linter-jshint ) wurden alle Problemumgehungen für das Melden fehlerhafter Punkte von JSHint entfernt. Der ganze Zweck dieser Prüfung besteht darin, Fehler wie diesen zu finden, bei denen der Linter ungültige Punkte meldet, damit sie für _jeder_, der den Linter verwendet, gemeldet und behoben werden können. (Wenn Sie sich nicht darauf verlassen können, dass der Linter Ihnen genaue Daten liefert, warum sollten Sie ihn dann verwenden?)

Es _kann_ einen "Sweet Spot" geben, bevor dieser Tab-Bug eingeführt wurde und nach den großen Parser-Bugs, die dazu führten, dass diese Problemumgehungen überhaupt erst eingeführt wurden.

@ Arcanemagus gotcha, weiß den Einblick wirklich zu schätzen. Mach weiter so 👍

Wenn Sie eine bessere/nützlichere Idee für eine Nachricht haben, wie linter-jshint diese ungültigen Punkte meldet, können Sie dort gerne ein Problem melden/eine PR einreichen 😉.

BITTE ALLE IHRE LÖSUNGEN SAUGEN ICH HABE DIE LETZTEN VERDAMMTEN 5 STUNDEN MIT DEM VERSUCHEN VERBUNDEN, EINE VERDAMMTE JAVASCRIPT-DATEI ZU LINTEN, SEIN VERDAMMTES 2017. WARUM HABE ICH DIESES PROBLEM, ATOM IST DER VERDAMMTE FLUCH MEINES VERDAMMTEN LEBENS, REPARIEREN SIE SICH SELBST, SIE DUMMER IDE

UND WER ZUM VERDAMMT VERWENDET KEINE REGISTERKARTEN, UM buchstäblich WTF EINZUSTELLEN, WARUM WÜRDEN SIE EIN DEFEKTES PAKET AN DIE MILLIONEN VERÖFFENTLICHEN, DIE LINT JS ???????

Wer verwendet nicht buchstäblich Punkte, warum geben Sie dieses gebrochene Englisch an die Millionen weiter, die Englisch ist?

Oh. Und Großbuchstaben stehen am Anfang eines Satzes. Nicht überall.

/Troll (sry, konnte mir nicht helfen)

Nun, ich denke, die Lösung wird sein, dies vorerst zu deaktivieren ...
Wer braucht schon Linters?

@jugglinmike Können Sie die Fragen in https://github.com/jshint/jshint/issues/3151#issuecomment -312512856 beantworten?

Ich habe 20 eindeutige Probleme offen für verschiedene Fälle, in denen dies ausgelöst wird, da es so aussieht, als würde die Behebung hier eine Weile dauern. Ich möchte mit der Problemumgehung fortfahren, vorausgesetzt, dass die Ergebnisse für die Benutzer dadurch nicht geändert werden.

Dieses Problem ist meinem Radar entglitten; Das tut mir leid, @Arcanemagus. Leider glaube ich nicht, dass ich dem Thema vor diesem Wochenende die Aufmerksamkeit widmen kann, die es verdient. Geht das so für dich?

@jugglinmike Natürlich 😉

Ich habe einige Überprüfungen auf vorhandene Probleme vorgenommen, sodass die meisten Leute auf die bereits offenen Probleme gefiltert werden, die hierher verweisen.

@cobexer Ich mag diese Idee, weil sie uns nicht nur einen Weg nach vorne gibt, sondern auch
könnte für Leute in anderen Kontexten nützlich sein. Das heißt, meines Wissens dort
Es gab noch nie eine Anfrage für diese Art von Funktionalität, und ich zögere, dies zu tun
verpflichten Sie sich zu jedem neuen Feature, nur weil es nett erscheint. Und es gibt Grund dazu
Entmutigen Sie insbesondere diese Funktion: zwischen "rc"-Dateien, inline
Konfiguration und der Node.js-API werden Benutzer bereits gestolpert, wenn sie wollen
um zu verstehen, warum eine bestimmte Option aktiviert ist. Hinzufügen eines weiteren Vektors für config
Das Management würde dieses Problem tendenziell verschärfen.

Ich denke, die praktikabelste Lösung hier basiert auf meiner früherenVorschlag .
Allerdings müssen wir die Eigenschaft character als öffentliche API betrachten – das Atom
Das Editor-Plugin ist schließlich selbst darauf aufgebaut. Also anstatt das zu ändern
Eigenschaft und die Definition einer neuen, die die Semantik der aktuellen hat, denke ich
Wir müssen character so lassen, wie es ist, und die angeforderten Daten auf einem neuen verfügbar machen
Name des Anwesens.

Ich habe dieses Wochenende mit der Arbeit an der neuen Funktion begonnen. Ich möchte Regressionen vermeiden
alle Kosten, also müssen wir die Tests des Projekts erweitern, um das konsequent durchzusetzen
erwartete Zeichenzahl. Als ich damit anfing, fand ich Mängel in der
Testsuite, die zuerst angegangen werden müssen. gh-3174 ist der erste Schritt in Richtung
dieses Ziel.

All dies soll sagen: Es sieht so aus, als könnte dies einige Zeit dauern. @ Arcanemagus Ich weiß
Sie tragen die Hauptlast dieses Fehlers, und ich weiß es zu schätzen, dass Sie dies als eine
Möglichkeit, JSHint verbessert zu sehen. Ich finde es auch gut, dass du dich dafür interessierst
Vermeidung von Lösungen, die für Ihre Benutzer nicht transparent sind. Kurz gesagt
Hatten Sie Glück, Benutzern zu empfehlen, die Option indent auf 1 zu setzen?
Es ist nicht ideal, aber es sollte ihr kurzfristiges Problem in gewisser Weise lösen
das wird weiter funktionieren, auch nachdem wir das gepatcht haben.

@Arcanemagus Ich weiß, dass Sie die Hauptlast dieses Fehlers tragen, und ich weiß es zu schätzen, dass Sie dies als eine nehmen
Möglichkeit, JSHint verbessert zu sehen.

Der einzige Grund, warum ich den Check zur generischen Bibliothek hinzugefügt habe, die von den meisten Linter-Anbietern für Atom verwendet wird, ist, dass Fehler wie dieser in den Quell-Linters abgefangen und gemeldet/behoben werden können 😉. Dies wäre eigentlich früher abgefangen worden, aber es gab eine Überprüfung in linter-jshint , die im Grunde alle ungültigen Punktfehler von _way_ zurück versteckte, als der Parser bei den meisten Dokumenten vollständig fehlschlug und wir keine nette Möglichkeit hatten, dies zu melden für Benutzer oder zum Deduplizieren von Problemberichten. Jetzt, da diese herausgefunden wurden, habe ich dieses Häkchen entfernt und hier sind wir 😛.

Mir gefällt auch, dass Sie daran interessiert sind, Lösungen zu vermeiden, die für Ihre Benutzer nicht transparent sind.

Eigentlich wäre eine transparente Lösung für dieses spezielle Problem in Ordnung, ich weiß nur nicht, ob das Erzwingen der indent -Einstellung auf 1 die Ergebnisse, die sie sehen, im Vergleich zu dem, was sie erhalten würden, ändern würde selbst jshint ausführen.

Hatten Sie kurzfristig Glück dabei, Benutzern zu empfehlen, die Einzugsoption auf 1 zu setzen?

Das ist... eine ausgezeichnete Idee, an die ich eigentlich nicht gedacht hatte, sie in diesen Ausgaben zu posten. Ich werde darauf achten, dies in den Kommentaren zu den Themen zu erwähnen!

Oh, ja, das Setzen der Eigenschaft „indent“ auf 1 in der .jshintrc-Datei ist eine hervorragende Problemumgehung. Ich wünschte, ich wüsste das früher. Ich habe bereits eine .jshintrc, weil jshint standardmäßig nicht es6 ist, also ist das einfach hinzuzufügen. 👍

Freut mich zu hören, @tustin2121!

Update: Ich arbeite immer noch daran, die JSHint-Testsuite zu stärken, um Regressionen zu vermeiden. Das neueste in dieser Anstrengung ist gh-3176.

Irgendwelche Updates zu diesem Thema?

Es sieht so aus, als wären jetzt mindestens 40 verschiedene Regeln von diesem Fehler betroffen 😛.

Irgendwelche Updates dazu, es ist einige Monate her, seit ich diese Fehler habe, die mich verrückt machen :)

Hallo @xcrap! Ich habe gerade den Kommentar-Thread überprüft, und es sieht nicht so aus, als hätte jemand irgendwelche Updates gepostet. Die gute Nachricht ist, dass JSHint ein Open-Source-Projekt ist, sodass Sie helfen können, das Problem zu beheben, wenn es Ihnen Stress bereitet! Sie möchten selbst Hand anlegen? Ich berate Sie gerne.

@jugglinmike Ich wünschte! Ich versuche es immer in kleinen Projekten, aber meine js-Fähigkeiten sind super einfach und begrenzt :)

Ich habe ein Kopfgeld von 50 $ auf diesen Fehler ausgesetzt, andere können über diesen Link dazu beitragen, das Kopfgeld zu erhöhen: https://www.bountysource.com/issues/46533252-tab-indentation-breaks-multiple-rules

Das lokale Einfügen des Forks von @tzvipm und das erneute Erstellen von jshint funktionierte, um das Problem für mich zu beheben, falls jemand anderes darüber stolpert:

git clone https://github.com/tzvipm/jshint
git remote add upstream [email protected]:jshint/jshint.git
git fetch upstream
git stash
git merge upstream/master
git mergetool --tool=opendiff
npm run build