Jshint: La advertencia de desactivación para W100 no funciona en 2.9.3

¡Gracias por el informe! Esto sí que es una regresión.

No es que te ayude mucho, pero parece que la nueva versión ha sacado a la luz un error que ya existía: en el proceso de reducir la entrada que compartiste, también pude experimentar este problema en la versión 2.9.2.

Necesito alejarme un poco, pero espero tener un parche listo esta noche (EST).

Aquí está la historia:

Al encontrar un carácter de paréntesis abierto ( ( ) en una expresión
posición, un analizador de JavaScript compatible con ES2015 como el de JSHint tiene que determinar
ya sea que marque el comienzo de un operador de agrupación o una función de flecha.

JSHint hace esto tokenizando toda la entrada que sigue hasta que encuentra un
carácter de paréntesis de cierre "coincidente" ( ) ). En ese momento, puede hacer una
determinación sobre la naturaleza de la producción en cuestión, si se sigue
por el token => , es una función de flecha; de lo contrario, es un operador de agrupación.

Mientras mira hacia el futuro, no aplica las directivas en línea que encuentra.
como -W100 . Sin embargo, el lexer es responsable de emitir ciertas pelusas.
errores _incluyendo_ W100 . Tan pronto como JSHint comienza a "mirar hacia adelante", su
el comportamiento en respuesta a estos personajes potencialmente peligrosos está "bloqueado".
(Eso sugiere una solución a corto plazo para cualquiera que sufra esta regresión: desactivar
W100 antes del IIFE. No es ideal, lo sé, pero tenga en cuenta que la relevancia de esose disputa la advertencia .)

Esta regresión se produjo debido a un parche aparentemente no relacionado: gh-3003.
Anteriormente, la anticipación se cancelaba si se colocaba un token de punto y coma.
encontrado, como en:

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

... sin embargo, se encontró que era una heurística inválida porque la función de flecha
los propios parámetros pueden contener ese token:

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

Así que lo eliminamos para reconocer correctamente las funciones de flecha en esos casos.

Con eso en mente, el caso de prueba completamente reducido puede ser un poco más claro (que
es un carácter \u200f no imprimible en el literal de la cadena):

(function() {
    ;

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

Antes de gh-3003 (p. ej., JSHint en la versión 2.9.2), el punto y coma detenía el
anticipación, y el carácter no imprimible no sería lexed hasta _después_ del
Se aplicó la directiva JSHint. Con la corrección aplicada, JSHint flexiona el carácter
_antes_ de aplicar la directiva y procede a advertir.

Esto también demuestra cómo existe el problema fundamental incluso en JSHint 2.9.2.
La siguiente entrada activa incorrectamente una advertencia incluso en esa versión de
JSHint:

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

Porque aquí, la búsqueda anticipada desencadenada por paréntesis no se interrumpe en ninguno de los dos
versión.

La solución ideal sería aplicar directivas durante la búsqueda anticipada. Desafortunadamente, debido
a la naturaleza altamente flexible de las directivas en línea de JSHint, esto no es
posible. Los usuarios esperan que las directivas tengan "alcance de función", lo que significa que el lexer
necesitaría ser consciente de la semántica circundante de los tokens que produce.

He enviado una solución aquí: gh-3016. A largo plazo, creo que deberíamos considerar
otras mejoras a la heurística de búsqueda anticipada, sin el punto y coma (no válido)
verificación, la práctica común de envolver programas completos en un IIFE causará
JSHint para leer inicialmente todas las entradas.

¡Gracias por la explicación detallada!
Veo lo complicado que puede ser esto sin agregar una inmensa cantidad de trabajo adicional para los ámbitos.
Nos quedaremos con 2.9.2 por un tiempo, ya que funciona para nuestros archivos y buscaremos dividir las partes problemáticas en bloques que podamos manejar en el futuro :)

La corrección de este error ya está disponible en la versión 2.9.4 de JSHint recién publicada:

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

¡Háganos saber si todavía tiene problemas con esa versión!