Jshint: Deaktivierungswarnung für W100 funktioniert nicht in 2.9.3

Danke für den Bericht! Das ist in der Tat ein Rückschritt.

Nicht, dass es Ihnen viel hilft, aber es sieht so aus, als ob die neue Version einen zuvor bestehenden Fehler aufgedeckt hat – im Prozess der Reduzierung der von Ihnen geteilten Eingaben konnte ich dieses Problem auch in Version 2.9.2 feststellen.

Ich muss mich etwas zurückziehen, aber ich hoffe, heute Abend (EST) einen Patch fertig zu haben.

Hier ist die Geschichte:

Beim Auffinden eines offenen Klammerzeichens ( ( ) in einem Ausdruck
Position muss ein ES2015-fähiger JavaScript-Parser wie der von JSHint ermitteln
ob es den Beginn eines Gruppierungsoperators oder einer Pfeilfunktion markiert.

JSHint tut dies, indem es alle folgenden Eingaben tokenisiert, bis es a findet
"übereinstimmendes" schließendes Klammerzeichen ( ) ). An diesem Punkt kann es eine machen
Entschlossenheit über die Art der fraglichen Produktion - wenn sie befolgt wird
beim Token => handelt es sich um eine Pfeilfunktion; andernfalls ist es ein Gruppierungsoperator.

Während es vorausschaut, wendet es keine Inline-Anweisungen an, auf die es stößt
wie -W100 . Der Lexer ist jedoch für die Emission bestimmter Flusen verantwortlich
Fehler _einschließlich_ W100 . Sobald JSHint also beginnt, "nach vorne zu schauen", ist es
Verhalten als Reaktion auf diese potenziell gefährlichen Charaktere ist "eingesperrt".
(Das schlägt eine kurzfristige Lösung für alle vor, die unter dieser Regression leiden: Deaktivieren
W100 vor dem IIFE. Nicht ideal, ich weiß, aber beachten Sie die Relevanz davonWarnung ist umstritten .)

Diese Regression ist auf einen anscheinend nicht verwandten Patch zurückzuführen: gh-3003.
Zuvor wurde die Vorausschau abgebrochen, wenn ein Semikolon-Token vorhanden war
begegnet, wie in:

(function() {
;//<-- lookahead ends at this semicolon token
}());

...das wurde jedoch wegen der Pfeilfunktion als ungültige Heuristik befunden
Parameter können selbst dieses Token enthalten:

(x = function() {
;//<-- lookahead should *not* end at this semicolon token
}) => x;

Also haben wir es entfernt, um Pfeilfunktionen in diesen Fällen richtig zu erkennen.

In Anbetracht dessen ist der vollständig reduzierte Testfall möglicherweise etwas klarer (das
ist ein nicht druckbares Zeichen \u200f im String-Literal):

(function() {
    ;

    /*jshint -W100 */
    "‏";
})();

Vor gh-3003 (z. B. JSHint bei Version 2.9.2) würde das Semikolon die
Lookahead, und das nicht druckbare Zeichen würde erst _nach_ dem lexed werden
Die JSHint-Direktive wurde angewendet. Wenn der Fix angewendet wurde, lext JSHint das Zeichen
_bevor_ die Richtlinie anwendet und fährt fort zu warnen.

Dies zeigt auch, wie das grundlegende Problem sogar in JSHint 2.9.2 besteht.
Die folgende Eingabe löst fälschlicherweise auch in dieser Version von eine Warnung aus
JSHint:

(function() {
    /*jshint -W100 */
    "‏";
})();

Denn auch hier wird der durch Klammern ausgelöste Lookahead nicht unterbrochen
Ausführung.

Die ideale Lösung wäre, während der Vorausschau Anweisungen anzuwenden. Leider fällig
Aufgrund der hochgradig flexiblen Natur der Inline-Anweisungen von JSHint ist dies nicht der Fall
möglich. Benutzer erwarten, dass Direktiven einen „Funktionsbereich“ haben, also den Lexer
müsste sich der umgebenden Semantik der von ihm produzierten Token bewusst sein.

Ich habe hier einen Fix eingereicht: gh-3016. Langfristig denke ich, sollten wir darüber nachdenken
andere Verbesserungen der Lookahead-Heuristik – ohne das (ungültige) Semikolon
überprüfen, wird die übliche Praxis, ganze Programme in ein IIFE zu verpacken, dazu führen
JSHint, um zunächst alle Eingaben zu lexen.

Danke für die ausführliche Erklärung!
Ich sehe, wie schwierig dies sein kann, ohne eine immense Menge an zusätzlicher Arbeit für Bereiche hinzuzufügen.
Wir werden eine Weile bei 2.9.2 bleiben, da es für unsere Dateien funktioniert, und werden versuchen, die problematischen Teile in Blöcke zu zerlegen, die wir in Zukunft verwalten können :)

Die Behebung dieses Fehlers ist jetzt in der neu veröffentlichten JSHint-Version 2.9.4 verfügbar:

http://jshint.com/blog/2016-10-20/release-2-9-4/

Bitte lassen Sie uns wissen, wenn Sie immer noch Probleme mit dieser Version haben!